- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Hi Rahat,
Healthchecks: Yes, this is an inherent tradeoff with healthchecks in any system design. The shorter the interval, the faster you can detect failures; but the more healthcheck load you're placing on your system. Generally healthcheck failures should be rare in a well designed system where updates are deployed to QA environments before prod, and so this shouldn't be an issue often. When it does happen, you should have a plan in place to make the experience as seemless for the end user as possible. For example, custom http error replies.
HTTPS: There are 2 separate HTTP connections when using an ALB
- Client to the ALB: This one needs a valid, signed certificate, to avoid your customers seeing warnings. You can easily provision one to use with the ALB via ACM
- ALB to targets (tasks): This connection can use a self-signed certificate. However, since this request is staying within the VPC, many environements are setup for this connection to be done over HTTP, and not HTTPS (unless there is a legal/compliance or similar policy requiring end-to-end HTTPS). This removes the load and latency from your tasks of having to handle the TLS connection
AutoScaling: Yes, if the ALBs target group is listed on the ECS Service configuration, all newly launched tasks will automatically be registered with the target group; and tasks being terminated will be deregistered
OpenSSL: I don't have any direct experience with setting this up in prod, so not going to speculate too much here. But if you end up not setting up end-to-end HTTPS as mentioned above, this becomes a moot point
Metrics in private subnets: No, the ECS service itself is sending the metrics default ECS metrics to CloudWatch, not your task. So the task does not need connectivity to CloudWatch (unless you're trying to push custom metrics, in which case yes, you do need connectivity from the Task to CloudWatch via a VPC Endpoint, NAT Gateway, etc). Similarly, the alarm is triggering AutoScaling, which is sending an UpdateService API call to the ECS service itself, not your tasks. So no connectivity concerns for the alarm either
Fargate: Just a quick terminology note, you mentioned "AutoScaling Group" further up in the question. An ASG is part of the EC2 AutoScaling service, and is used to autoscale EC2 instances. For an ECS Service, you use an Application AutoScaling Scalable Target
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa
Nice! But you didn't tell anything regarding service connect! Does service connect works on top for serving https! if we decide to encrypt our traffic from ALB to our task using self signed certificates! Because i was just thinking to securely pass the traffic from the ALB which is in public subnet to the broker service in private subnet and then rely on http for grpc communication between internal services! (because i don't want any case where a hacker get through the internet gateway then snicking out the decrypted outbound traffic of my ALB!)
I've never used Service Connect, so not sure on that part. From a quick review of the main Service Connect doc, it looks like this is basically just a service discovery feature using DNS, so I would assume HTTP vs HTTPS wouldn't make a difference to it.
But in general, if someone has hacked into your environment, it would generally have to be one of your instances/tasks, and the traffic is being decrypted on those for the application to read anyway.
Thanks for replying! Not a big deal I also hope the same that it should not make a difference ! Soon I am going to try that thing!