S3-yhdyskäytävä vai liitäntäpäätepiste paikalliselle asiakkaalle?

S3:een pääseminen toimistoverkosta site-VPN:n kautta ei ole reititysongelma, jonka staattinen reitti ratkaisisi yksin. Yhdyskäytävän päätepiste liitetään reititystaulukoihin ja palvelee pyyntöjä, jotka syntyvät VPC:n sisällä. Liitäntäpäätepiste sijoittaa joustavia verkkoliitäntöjä yksityisine osoitteineen aliverkkoihisi, ja nämä osoitteet ovat paikallisesta verkosta saavutettavissa VPN:n tai Direct Connectin kautta. Se, mistä pyyntö alkaa, ratkaisee, kumpaa kahdesta todella tarvitset, ja DNS-, tietoturvaryhmä- ja käytäntötyö seuraa siitä vastauksesta.

Erottele päätepistetyypit sen mukaan, mistä pyyntö alkaa

Yhdyskäytävän päätepiste näkyy reititystaulukon merkintänä, joka osoittaa hallittuun etuliiteluetteloon. Sillä ei ole verkkoliitäntää, tietoturvaryhmää eikä omaa yksityistä osoitetta, ja juuri siksi paikallinen isäntä ei voi reitittää siihen: toisella puolella ei ole mitään, mihin reitittää. VPC:n sisältä tuleva liikenne saavuttaa S3:n, koska aliverkon reititystaulukko lähettää kyseisen etuliitteen päätepisteelle. Muualta tulevalla liikenteellä ei ole sellaista merkintää seurattavanaan.

Liitäntäpäätepiste on joukko verkkoliitäntöjä valitsemissasi aliverkoissa, kullakin yksityinen osoite kyseisestä aliverkosta ja liitetty tietoturvaryhmä. Tämä on muoto, jota hybridiasiakas voi käyttää, koska se on tavallinen kohde, johon tunnelisi voi kuljettaa paketteja. Se tarkoittaa myös, että päätepiste kuluttaa osoitteita aliverkossa ja voi käyttää ne loppuun.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Lue Type-sarake nimen sijaan. Yksi VPC sisältää yleensä molemmat tyypit samalle palvelulle, ja merkintä, jonka paikallinen sovelluksesi tarvitsee, on liitäntämerkintä.

Rakenna polku liitäntäosoitteeseen ennen S3:n testaamista

Kolmen asian on oltava totta samanaikaisesti: paikallisella reitittimellä on reitti päätepisteen aliverkkoon, kyseisen aliverkon paluupolku saavuttaa asiakasverkon, ja päätepisteen tietoturvaryhmä sallii asiakkaan lähdeavaruuden. Aliverkon verkon ACL voi silti pudottaa paketin, vaikka kaikki kolme täyttyvät, joten tarkista se neljäntenä kohtana eikä jälkikäteen tulleena ajatuksena.

Toimiva reitti johonkin VPC:n EC2-instanssiin ei todista tästä mitään. Se näyttää, että tunneli on pystyssä, mikä on ainoa polun osa, jonka tiesit jo. Todista päätepisteen osoite erikseen ja todista sitten, että nimi ratkeaa siihen.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

Ensimmäinen komento näyttää, mitä liitäntää asiakas käyttäisi. Toinen todistaa TCP-kättelyn. Kolmas todistaa, että TLS suoritetaan loppuun päätepisteen nimelle kelvollisella varmenteella, ja juuri se tarkistus nappaa väärän osoitteen ennen kuin syytät käyttöoikeuksia.

Päätä, minkä DNS-vastauksen sovellus saa

Liitäntäpäätepisteen olemassaolo VPC:ssä ei ohjaa paikallista SDK:ta uudelleen itsestään. Asiakas käyttää joko päätepistekohtaista nimeä, jonka AWS julkaisee kyseiselle päätepisteelle, tai yksityistä ylläpidettyä vyöhykettä, jonka olet tarkoituksella tehnyt toimistosta ratkeavaksi.

Hybridiratkaisua varten paikallinen ratkaisija tarvitsee tuetun polun VPC:n DNS-näkymään, yleensä Resolverin saapuvan päätepisteen kautta. Yksityisen DNS:n käyttöönotto ymmärtämättä, mihin kyselylähteisiin se vaikuttaa, johtaa siihen, että haku alkaa palauttaa osoitetta, johon toimisto ei pääse. Asetus muuttaa vastauksia kyselyille, jotka tulevat VPC:n ratkaisijan kautta, ei jokaiselle asiakkaalle kaikkialla.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Suorita molemmat sovelluksen isännällä, älä VPC:n hyppylaatikolla. Siellä vastaava ratkaisija on se, jota työkuormasi käyttää, ja eri vastaus eri isännältä on tämän suunnittelun yleisin sekaannuksen lähde.

Saavutettavuus ei ole valtuutus

Päätepisteelle saapuva pyyntö tarvitsee edelleen valtuutetun päämiehen ja sovellettavan ämpärikäyttöoikeuden. Päätepistekäytäntö voi kaventaa sitä, mitä päätepiste sallii, ja ämpärikäytäntö voi kaventaa sitä edelleen. Liitäntään pääseminen ei kerro mitään siitä, mitä objekteja kutsuja saa lukea.

Testaa molemmat suunnat: yksi harmiton valtuutettu kutsu aiottuun ämpäriin ja yksi kutsu, jonka odotetaan hylättävän käytännön ulkopuoliselle identiteetille tai resurssille. Säilytä päätepisteen nimi, ratkennut osoite ja käytännön konteksti tuloksen kanssa, jotta seuraava henkilö voi toistaa sen. Hylkäys, joka nimeää käytännön tyypin, säästää tunnin arvailua.

Arvioi lopuksi kahden vaihtoehdon hinta ennen käyttöönottoa. Liitäntäpäätepiste laskutetaan liitäntätunnin ja gigatavun mukaan, yhdyskäytävän päätepiste ei, ja tämä ero ratkaisee kysymyksen monille pienivolyymisille työkuormille, jotka tarvitsevat vain pääsyn VPC:n puolelta.