Observability

Reading VPC Flow Logs

Once flow logs are publishing to CloudWatch, navigate to CloudWatch > Log Groups and find the group you created. Each log stream corresponds to an ENI. A flow log record looks like this:

2 123456789012 eni-0abc1234 10.0.11.5 8.8.8.8 54321 53 17 1 76 1609459200 1609459260 ACCEPT OK

The fields, in order: version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status.

An ACCEPT record means the traffic was permitted. A REJECT record means a security group or NACL blocked it. When you cannot reach a service, the first diagnostic step is to check flow logs for REJECT records originating from your source instance’s private IP.

Common debugging scenario: Your application tier cannot reach the database. You check sg-db and it looks correct. You pull flow logs for the database ENI and see REJECT records coming from the app instance’s IP. This tells you the security group rule is the problem. If you see no records at all for that pair, the problem is routing — traffic is not arriving at the DB subnet.

Health Checks

If you later deploy an Application Load Balancer in front of your application tier, configure health checks to target your application’s health endpoint (e.g., GET /health HTTP/1.1). The ALB uses these to determine which targets to route traffic to. A target that fails health checks is removed from rotation without any manual intervention.

The network layer you built today is what allows health checks to work: the ALB (in sg-lb) can reach app instances (in sg-app) because the security group chain permits it. Health check failures that are actually network failures will appear as connection timeouts in the ALB access logs.