You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The application will typically need to make egress connections to various services, e.g. ECR, New Relic, Splunk, or other 3rd party services, and other system-to-system APIs.
Usually it's impractical to limit these using IP address allow lists, due to CDNs or other ways that IPs frequently change or are shared.
Instead, consider implementing an egress proxy. This could be an instance of squid (or something else) that runs in Fargate. It would be configured with an allow list of domain names. Unexpected requests would be denied and alert an admin.
The application would have a security group only allow egress to the proxy, and all libraries would be configured to use it (e.g. https_proxy env variable).
The application will typically need to make egress connections to various services, e.g. ECR, New Relic, Splunk, or other 3rd party services, and other system-to-system APIs.
Usually it's impractical to limit these using IP address allow lists, due to CDNs or other ways that IPs frequently change or are shared.
Instead, consider implementing an egress proxy. This could be an instance of squid (or something else) that runs in Fargate. It would be configured with an allow list of domain names. Unexpected requests would be denied and alert an admin.
The application would have a security group only allow egress to the proxy, and all libraries would be configured to use it (e.g. https_proxy env variable).
See Providing controlled internet access through centralised proxy servers using AWS Fargate and PrivateLink | Networking & Content Delivery for an example.
Instead of squid, it might be possible to use AWS Network Firewall. See Migrating from Squid Web Proxy to AWS Network Firewall | Networking & Content Delivery
The text was updated successfully, but these errors were encountered: