1

I have been using AWS for hosting personal projects, mostly in the form of containerized Django web apps running on ECS with Fargate. I have referenced this article to better understand Fargate task networking: https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/

I understand that tasks can be launched in either public or private subnets, and that a task that requires internet access that is placed in a private subnet must use a NAT Gateway/instance in a public subnet.

I'm trying to understand how the "Best Practices for Fargate Networking" section of the Fargate Networking article linked above applies to my application architecture and security.

If you are running a service that handles private, internal information, you should not put it into a public subnet or use a public IP address. For example, imagine that you have one task, which is an API gateway for authentication and access control. You have another background worker task that handles sensitive information.

The intended access pattern is that requests from the public go to the API gateway, which then proxies request to the background task only if the request is from an authenticated user. If the background task is in a public subnet and has a public IP address, then it could be possible for an attacker to bypass the API gateway entirely. They could communicate directly to the background task using its public IP address, without being authenticated.

For personal projects, I'm generally trying to avoid any unnecessary costs. NAT Gateway costs can be avoided by running my Django/gunicorn and Celery workers in public subnets and keeping my postgres and redis databases in private/isolated subnets. This saves money, but it breaks the best practices described in the Fargate Networking article.

I'm curious to understand how much of a security risk this poses, and what else I could do to harden security in my VPC if without using a NAT Gateway/instance.

Community
  • 1
briancaffey
  • 143
  • 1
  • 5

1 Answers1

3

Public subnet means that the instances can be directly accessible from the internet with their public IP address (or EIP). There are a lot of bots constantly crawling IP addresses. If they get a response from a server, they know that it could be potentially be breached or bruteforced.

I understand the cost consideration and I would make use of NACL (first) + Security group.(first and second). NACL is setup on the subnet level, protecting all the instances within that subnet. Security group is on the instance level, meaning it can be forgotten and leave the instance to the mercy of "hackers".

Kaymaz
  • 228
  • 1
  • 6
  • thanks @Kaymaz, this helps clarify. I remember learning about NACL, and I'll see if I can work that into my network configuration. – briancaffey May 25 '20 at 23:39