Utilize S3 Gateway Endpoint in centralized AWS Network Account with AWS Network Firewall

0

Dead community,

Situation:

Target situation:

  • To reduce costs for NAT data processing, we want to utilize an S3 Gateway Endpoint (not an S3 interface endpoint) for S3 traffic instead of NAT Gateway
  • S3 Gateway endpoint is free of charge, NAT gateway or S3 interface endpoint is not
  • Keeping S3 Gateway endpoint in all "spoke accounts" is no option because we would have no clue what data is leaving our AWS environment towards S3 bucket (from potentially anyone in Public Internet)

Challenge:

  • Acc. to AWS documentation: "Endpoint connections cannot be extended out of a VPC. Resources on the other side of a VPN connection, VPC peering connection, transit gateway, or AWS Direct Connect connection in your VPC cannot use a gateway endpoint to communicate with Amazon S3."

Expert support requested:

  • Is is possible to utilize S3 Gateway Endpoint in centralized Network Account with AWS Network Firewall?

My idea:

  • Setting up R53 Private Hosted Zone in central Network Account and
  • point to AWS Network Firewall VPCE.
  • The AWS Network Firewall is in a subnet with S3 Gateway Endpoint and
  • a Route Table Entry for S3 Prefix List to S3 Gateway Endpoint.
  • Share the PHZ with all "spoke AWS Accounts"

Will such a setup work / any hints for best practices? Unfortunately I cannot find any documentation about centralized S3 Gateway Endpoint.

1 Answer
2
Accepted Answer

Is is possible to utilize S3 Gateway Endpoint in centralized Network Account with AWS Network Firewall?

No. Gateway Endpoints are only accessible from the VPC in which they are hosted.

In the environment that you have described you must either use Interface Endpoints in the central network account; or run a proxy fleet in the central network account for S3 access to the Gateway Endpoint (because then traffic will appear to come from the proxy fleet rather than the source VPC).

Note that you have the ability to control what is access through the endpoint(s) using endpoint policies so that's a good way to control access. With many accounts and distributed Gateway Endpoints I'd suggest that automation is your friend here.

Traffic to S3 is going to be encrypted (well, at least 99.99% of it). Inspecting that requires you to break TLS (something I'm not in favour of) - and doing that requires that some client libraries have certificate checking disabled which may or may not be possible depending on the application using that library. Disabling certificate checking means that the encryption can no longer be trusted - so be careful there.

Keeping S3 Gateway endpoint in all "spoke accounts" is no option because we would have no clue what data is leaving our AWS environment towards S3 bucket (from potentially anyone in Public Internet)

A user on the public internet can't use a Gateway Endpoint to reach a S3 bucket. I think this needs some clarification because you say "leaving our environment towards S3" (which is what I would expect - in addition to sending data to S3); but "from potentially anyone in public internet" doesn't compute in this sense.

profile pictureAWS
EXPERT
answered a month ago
  • First of all, thanks for this comprehensive response! ** Reg. "proxy fleet in the central network account for S3 access to the Gateway Endpoint": I was assuming that MAYBE the AWS Network Firewall (NFW) would act as such a proxy. But it will not work after some investigation. (my idea was: A PHZ in central Network account points S3-requests from "Spoke Accounts" towards AWS NFW in central Network Account. The NFW itself is deployed in a subnet with a Route Table entry towards S3 Gateway Endpoint. But this will not work. It will at least fail because resolver rules logic is as follows acc. to my investigation: a) Forward Rules, b) Private DNS / PHZ, c) VPC DNS (incl. S3 Prefix List), d) Public DNS) ** Reg. "no clue what data is leaving our AWS environment towards S3 bucket (from potentially anyone in Public Internet)" - What I was trying to say is: the source is in our AWS environment, the target can be an S3 bucket from our AWS environment, or an S3 bucket from a "hacker" AWS environment. But in the end you answered it already: Restricting access trough VPC endpoint policies would be the way to go here. ** Any idea on how the VPC endpoint policies can be governed from a central location?
    Main purpose of the Network account was to have one place where the Network team can configure all Network items. Moving S3 endpoints to the "Spoke Accounts" means the Network team must ensure the endpoint policies are all set correctly.

  • Yes, it's a common challenge in distributed environments where centralized teams (networking, security, etc.) have challenges dealing with resources in other accounts. My best advice here is to have those teams embrace automation and use appropriately scoped cross-account roles to perform those tasks. While there is definitely some ramp-up in terms of knowledge (and time) the benefits going forward (especially in AWS where automation is encouraged) are huge. And this is coming from and 'old-skool' network engineer...

  • Thanks for sharing your advice!

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions