What's the most appropriate and secure way to setup a ECS task - Elastic Cache Cluster connection?

Question

I've got a Elastic Cache cluster and a ECS service which share a subnet and a security group with the following description:

{
    "SecurityGroups": [
        {
            "Description": "Allow Redis inbound traffic",
            "GroupName": "allow_redis_ingress",
            "IpPermissions": [
                {
                    "FromPort": 6379,
                    "IpProtocol": "tcp",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0",
                            "Description": "Redis"
                        }
                    ],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "ToPort": 6379,
                    "UserIdGroupPairs": []
                }
            ],
            "OwnerId": "aws_account_id",
            "GroupId": "sg-xxxxxxxxxxxx33290",
            "IpPermissionsEgress": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "Ipv6Ranges": [
                        {
                            "CidrIpv6": "::/0"
                        }
                    ],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": []
                }
            ],
            "Tags": [
                {
                    "Key": "Environment",
                    "Value": "production"
                },
                {
                    "Key": "Private",
                    "Value": "true"
                }
            ],
            "VpcId": "vpc-xxxxxxxxxxxx380b4"
        }
    ]
}

I'm wondering if this is the most appropriate way to set up security permissions as they're in the same security group. Is it?

I got two CodeBuild projects which have the same subnet and security group in common, these two projects access to a cache node of the cluster without any issues.

Should I even create a dedicated subnet AND security group for the cluster subnet and instead allow ingress from the tasks and codebuild project security groups even from another subnet?

For connection to the cluster, I'm using the cache node cache.amazonaws.com URL, is this correct or would there be a safer way to route any localhost:6379 or even cache:6379 host url to the Elastic Cache cluster nodes automatically?

Answer 1

Should I even create a dedicated subnet AND security group for the cluster subnet and instead allow ingress from the tasks and codebuild project security groups even from another subnet?

A dedicated subnet is not needed. However a dedicated security group is absolutely needed. Assigning multiple services of different types to the same security group is an anti-pattern. Assigning them to the same security group provides no benefit, and makes it difficult to properly restrict traffic.

You should create a security group for Elasticache, and another security group for your ECS service. Then, in your Elasticache security group you should create an inbound rule for port 6379 that allows traffic from the security group assigned to the ECS service. You would do this by specifying security group ID in the inbound rule, instead of CIDR block.

For connection to the cluster, I'm using the cache node cache.amazonaws.com URL, is this correct or would there be a safer way to route any localhost:6379 or even cache:6379 host url to the Elastic Cache cluster nodes automatically?

Well localhost obviously isn't going to work because they aren't on the same host.

You could add a Route53 private hosted zone to the VPC, and then create a DNS entry for something like cache.mydomain that points to the Elasticache cluster. However the way you are currently doing it, with the "cache.amazonaws.com" endpoint URL is totally fine, and if you ever wanted to do SSL verification on your connections you would have to use that URL.