S3 gateway o interface endpoint para sa kliyenteng nasa lugar?

Ang maabot ang S3 mula sa network ng opisina sa pamamagitan ng site VPN ay hindi problema sa routing na kayang lutasin ng static na ruta nang mag-isa. Ang gateway endpoint ay nakakabit sa mga talahanayan ng ruta at naglilingkod sa mga kahilingang nagmumula sa loob ng VPC. Ang interface endpoint ay naglalagay ng elastic na mga interface ng network na may pribadong address sa iyong mga subnet, at ang mga address na iyon ay maaabot mula sa lugar sa pamamagitan ng VPN o Direct Connect. Kung saan nagsisimula ang kahilingan ang nagtatakda kung alin sa dalawa ang talagang kailangan mo, at ang gawain sa DNS, security group at patakaran ay sumusunod mula sa sagot na iyon.

Paghiwalayin ang mga uri ng endpoint ayon sa kung saan nagsisimula ang kahilingan

Ang gateway endpoint ay lumilitaw bilang entry sa talahanayan ng ruta na tumuturo sa isang pinamamahalaang listahan ng prefix. Wala itong interface ng network, security group o sariling pribadong address, at iyon mismo ang dahilan kung bakit hindi ito marurutan ng host sa lugar: walang anuman sa kabilang panig na marurutan. Naabot ng trapiko mula sa loob ng VPC ang S3 dahil ipinapadala ng talahanayan ng ruta ng subnet ang prefix na iyon sa endpoint. Ang trapiko mula saanman ay walang ganoong entry na masusundan.

Ang interface endpoint ay isang set ng mga interface ng network sa mga subnet na pipiliin mo, bawat isa ay may pribadong address mula sa subnet na iyon at nakakabit na security group. Ito ang hugis na magagamit ng hybrid na kliyente, dahil ordinaryong destinasyon ito na kayang dalhin ng iyong tunnel ng mga packet. Nangangahulugan din ito na ang endpoint ay gumagamit ng mga address sa subnet at maaaring maubos ang mga ito.

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

Basahin ang column na Type at hindi ang pangalan. Karaniwang may parehong uri ang isang VPC para sa parehong serbisyo, at ang entry na kailangan ng iyong aplikasyon sa lugar ay ang entry ng interface.

Buuin ang landas patungo sa address ng interface bago subukan ang S3

Tatlong bagay ang dapat totoo nang sabay: may ruta ang router sa lugar patungo sa subnet ng endpoint, naaabot ng pabalik na landas mula sa subnet na iyon ang network ng kliyente, at pinapayagan ng security group ng endpoint ang hanay ng pinagmulan ng kliyente. Maaari pa ring itapon ng network ACL ng subnet ang packet pagkatapos na makapasa ang tatlo, kaya tingnan ito bilang ikaapat na item at hindi bilang huling-isip.

Ang gumaganang ruta patungo sa alinmang EC2 instance sa VPC ay hindi nagpapatunay ng anuman dito. Ipinapakita lamang nito na nakataas ang tunnel, na siyang tanging bahagi ng landas na alam mo na. Patunayan ang address ng endpoint nang hiwalay, pagkatapos ay patunayang nare-resolve ang pangalan doon.

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

Ipinapakita ng unang utos kung aling interface ang gagamitin ng kliyente. Pinatutunayan ng ikalawa ang TCP handshake. Pinatutunayan ng ikatlo na nagtatapos ang TLS na may sertipikong balido para sa pangalan ng endpoint, at iyon ang pagsusuring nakakahuli ng maling address bago mo sisihin ang mga pahintulot.

Magpasya kung aling sagot ng DNS ang natatanggap ng aplikasyon

Ang pagkakaroon ng interface endpoint sa VPC ay hindi kusang nagre-redirect ng SDK sa lugar. Ginagamit ng kliyente ang pangalang partikular sa endpoint na inilalathala ng AWS para sa endpoint na iyon, o isang pribadong naka-host na zone na sinadyang mong gawing resoluble mula sa opisina.

Para sa hybrid na resolusyon, kailangan ng resolver sa lugar ng suportadong landas papasok sa view ng DNS ng VPC, karaniwang sa pamamagitan ng inbound na endpoint ng Resolver. Ang pagpapagana ng pribadong DNS nang hindi nauunawaan kung aling mga pinagmumulan ng query ang naaapektuhan nito ay ang paraan kung paano nagsisimulang magbalik ang isang paghahanap ng address na hindi maabot ng opisina. Binabago ng setting ang mga sagot para sa mga query na dumarating sa pamamagitan ng resolver ng VPC, hindi para sa bawat kliyente saanman.

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

Patakbuhin ang pareho sa host ng aplikasyon, hindi sa jump box sa loob ng VPC. Ang resolver na sumasagot doon ang gamit ng iyong workload, at ang ibang sagot mula sa ibang host ang pinakakaraniwang pinagmumulan ng kalituhan sa disenyong ito.

Ang maabot ay hindi awtorisasyon

Ang kahilingang dumarating sa endpoint ay nangangailangan pa rin ng awtorisadong principal at naaangkop na pahintulot sa bucket. Maaaring paliitin ng patakaran ng endpoint ang ipinapahintulot ng endpoint, at maaari pang paliitin ng patakaran ng bucket. Ang maabot ang interface ay walang sinasabi tungkol sa kung aling mga bagay ang mababasa ng tumatawag.

Subukan ang parehong direksyon: isang awtorisado at walang pinsalang tawag laban sa nilalayong bucket, at isang tawag na inaasahang tatanggihan para sa pagkakakilanlan o resource sa labas ng patakaran. Itago ang pangalan ng endpoint, ang na-resolve na address at ang konteksto ng patakaran kasama ng resulta para maulit ito ng susunod na tao. Ang pagtanggi na nagpapangalan ng uri ng patakaran ay nakakatipid ng isang oras sa hula.

Sa huli, tantiyahin ang halaga ng dalawang opsyon bago mag-provision. Ang interface endpoint ay sinisingil kada oras ng interface at kada gigabyte, samantalang ang gateway endpoint ay hindi, at ang pagkakaibang iyon ang nagtatakda ng tanong para sa maraming workload na mababa ang volume na kailangan lamang ng access mula sa panig ng VPC.