S3 портал или интерфејсна крајна точка за локален клиент?

Да се стигне до S3 од канцелариска мрежа преку site VPN не е проблем за рутирање што статична рута може сама да го реши. Крајната точка на порталот се прикачува на табелите за рутирање и служи барања што настануваат внатре во VPC. Интерфејсната крајна точка поставува еластични мрежни интерфејси со приватни адреси во вашите подмрежи, и тие адреси се достапни од локацијата преку VPN или Direct Connect. Каде започнува барањето одлучува која од двете всушност ви треба, а работата на DNS, безбедносната група и политиката произлегува од тој одговор.

Одделете ги типовите крајни точки според тоа каде започнува барањето

Крајната точка на порталот се појавува како запис во табелата за рутирање што покажува на управуван список со префикси. Нема мрежен интерфејс, безбедносна група и сопствена приватна адреса, и токму затоа локален домаќин не може да рутира кон неа: од другата страна нема ништо кон што би се рутирало. Сообраќајот од внатрешноста на VPC стигнува до S3 затоа што табелата за рутирање на подмрежата го испраќа тој префикс до крајната точка. Сообраќајот од каде било на друго место нема таков запис што би го следел.

Интерфејсната крајна точка е збир мрежни интерфејси во подмрежите што ги избирате, секој со приватна адреса од таа подмрежа и прикачена безбедносна група. Тоа е формата што хибриден клиент може да ја користи, бидејќи е обична дестинација до која вашиот тунел може да носи пакети. Тоа исто така значи дека крајната точка троши адреси во подмрежата и може да ги исцрпи.

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

Читајте ја колоната Type, а не името. Еден VPC обично држи двата типа за истата услуга, а записот што му е потребен на вашата локална апликација е интерфејсниот.

Изградете ја патеката до адресата на интерфејсот пред да го тестирате S3

Три работи мора да бидат точни истовремено: рутерот на локацијата има рута до подмрежата на крајната точка, повратната патека од таа подмрежа стигнува до клиентската мрежа, и безбедносната група на крајната точка го дозволува опсегот на изворот на клиентот. Мрежниот ACL на подмрежата сепак може да го отфрли пакетот откако сите три ќе поминат, затоа проверете го како четврта ставка, а не како подоцнежна мисла.

Работна рута до некоја EC2 инстанца во VPC не докажува ништо од ова. Таа покажува дека тунелот е кренат, што е единствениот дел од патеката што веќе го знаевте. Докажете ја адресата на крајната точка одделно, потоа докажете дека името се решава кон неа.

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

Првата команда покажува кој интерфејс клиентот би го користел. Втората докажува ракување TCP. Третата докажува дека TLS завршува со сертификат валиден за името на крајната точка, и токму таа проверка фаќа погрешна адреса пред да ги обвините дозволите.

Одлучете кој одговор од DNS го добива апликацијата

Постоењето интерфејсна крајна точка во VPC не го пренасочува локалниот SDK само по себе. Клиентот или го користи името специфично за крајната точка што AWS го објавува за неа, или приватна хостирана зона што намерно сте ја направиле решлива од канцеларијата.

За хибридно решавање, локалниот решавач има потреба од поддржана патека во DNS приказот на VPC, обично преку влезна крајна точка на Resolver. Вклучувањето приватно DNS без разбирање на кои извори на барања влијае е начинот на кој пребарувањето почнува да враќа адреса до која канцеларијата не може да стигне. Поставката ги менува одговорите за барањата што доаѓаат преку решавачот на VPC, не за секој клиент насекаде.

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

Извршете ги двете на домаќинот на апликацијата, не на скокачка кутија во VPC. Решавачот што одговара таму е оној што го користи вашето работно оптоварување, а различен одговор од различен домаќин е најчестиот извор на забуна во овој дизајн.

Достапноста не е авторизација

Барањето што пристигнува на крајната точка се уште бара овластен субјект и применлива дозвола за корпа. Политиката на крајната точка може да го стесни она што крајната точка го дозволува, а политиката на корпата може повторно да го стесни. Да се стигне до интерфејсот не кажува ништо за тоа кои објекти повикувачот смее да ги чита.

Тестирајте ги двата правци: еден безопасен овластен повик кон предвидената корпа и еден повик што се очекува да биде одбиен за идентитет или ресурс надвор од политиката. Чувајте го името на крајната точка, решената адреса и контекстот на политиката заедно со резултатот за следниот човек да може да го повтори. Одбивање што го именува типот на политика заштедува еден час нагаѓање.

На крајот, проценете ја цената на двете опции пред обезбедувањето. Интерфејсната крајна точка се наплатува по час на интерфејс и по гигабајт, додека порталната не, и таа разлика го решава прашањето за многу оптоварувања со мал обем на кои им треба само пристап од страната на VPC.