Exam-style
An assistant runs on ECS in a private subnet and calls Amazon Bedrock through a NAT gateway. Security asks the team to stop that traffic traversing the public internet, so they add an interface VPC endpoint for the Bedrock runtime using AWS PrivateLink. The security lead then updates the control register with two entries: model traffic is now encrypted, and access to Bedrock is now restricted. Which reading of those two entries is right?
Reveal the answer
B. The encryption entry is wrong, because TLS was already encrypting the call before the endpoint existed and the endpoint changed the route rather than the ciphertext. The access entry is right only if an endpoint policy was attached to say which principals and which models may pass through
Three separate controls are being fused into one here, and they do three different jobs. AWS PrivateLink changes the network path. An interface VPC endpoint puts a private IP address for the Bedrock APIs inside the team’s own subnets, so the SDK call resolves to that address and reaches the service across the AWS network instead of leaving through an internet gateway. Nothing about the payload changes. TLS is what encrypts the request in transit, and it was encrypting that same request the day before the endpoint existed, when the traffic went out through the NAT gateway. AWS KMS is what encrypts the prompts, documents and outputs the application stores, which is the at-rest half of the pair. So the encryption entry in the register is recording a benefit the team already had. The genuine gain that comes with the endpoint is the endpoint policy: a resource policy on the endpoint itself that names which principals may use this door and which models they may reach through it, evaluated on top of whatever the calling role’s IAM policy allows. Attach one and the access entry is honest; leave it off and the endpoint is open to anything in the VPC that already has credentials. The fifth option gets the first half right and then overreaches. An interface endpoint governs traffic that goes through it, and it does not close the public Bedrock endpoint to a set of credentials used from somewhere else, which is a job for IAM conditions rather than the endpoint. The fourth option throws out something worth recording: alongside the endpoint policy, dropping the NAT gateway from that route removes both a hop and its per-gigabyte egress charge.
Q. The team adds an interface VPC endpoint for Bedrock and records the traffic as encrypted and access as restricted. Which entry is wrong?
A. The encryption entry. AWS PrivateLink changes the route, not the ciphertext, and the access entry only holds up if an endpoint policy was attached.
Why? Keep three controls apart. AWS PrivateLink puts a private IP address for the Bedrock APIs in your own subnets, so the call reaches the service over the AWS network rather than out through an internet gateway. TLS encrypts the request in transit and was already doing so through the NAT gateway. AWS KMS encrypts what gets stored, and together those two are what the guide means by encryption at rest and in transit. The endpoint’s own policy is the one real access-control gain, naming which principals and which models may be reached through this door on top of the caller’s IAM policy, and it does nothing until somebody writes it. Two things worth carrying: an endpoint with no policy restricts nobody, and the NAT gateway that route no longer needs was costing money by the gigabyte.