Seems your drop rule wins your allow rules and cause the unexpected result, please use alert instead for your debug:

alert ip $HOME_NET any -> $EXTERNAL_NET any (msg:"Debug unauthorized traffic"; flow:to_server; sid:1100; rev:1;)

More specify on outbound unwanted traffic like below:

drop ip $HOME_NET any -> !$ALLOWED_DOMAINS any (msg:"Block unauthorized"; flow:to_server; sid:1100; rev:1;)

Making a few assumptions here (i.e. that your firewall configuration is set to use "strict rule ordering") - The issue is that once you add in that drop rule, you don't have anything in your rule configuration that will allow the TCP handshake to complete. I'd take a look at the sample rule set in the best practise guide below to get an idea of how to build this out: https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/

IP protocol is evaluated first because it's a low level protocol ( compared to TCP and TLS ). Therefore, regardless of the configured "Strict Order," IP drop rule will be evaluated first.

Looking on DOC previously shared ( https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/ ) you have lots of rules examples. I validated the following rules in my lab ( with google domain ) and they worked:

pass tls $HOME_NET any -> any 443 (msg:"Allow google.com"; tls.sni; content:"google.com"; nocase; flow:to_server; sid:1002; rev:1;)

reject tls $HOME_NET any -> any any (msg:"Default Egress HTTPS Reject"; ssl_state:client_hello; flowbits:set,blocked; flow:to_server; sid:999991;) alert tls $HOME_NET any -> any any (msg:"X25519Kyber768"; flowbits:isnotset,blocked; flowbits:set,X25519Kyber768; noalert; flow:to_server; sid:999993;)

reject http $HOME_NET any -> any any (msg:"Default Egress HTTP Reject"; flowbits:set,blocked; flow:to_server; sid:999992;) reject tcp $HOME_NET any -> any any (msg:"Default Egress TCP Reject"; app-layer-protocol:!tls; flowbits:isnotset,blocked; flowbits:isnotset,X25519Kyber768; flow:to_server; sid:999994;) drop udp $HOME_NET any -> any any (msg:"Default Egress UDP Drop"; flow:to_server; sid:999995;) drop icmp $HOME_NET any -> any any (msg:"Default Egress ICMP Drop"; flow:to_server; sid:999996;)

drop ip $HOME_NET any -> any any (msg:"Default Egress IP Drop"; ip_proto:!TCP; ip_proto:!UDP; ip_proto:!ICMP; flow:to_server; sid:999997;)

Note that TCP protocol evaluation comes before TLS protocol evaluation. This is why I added "app-layer-protocol:!tls" to the TCP Reject Rule.

Strong assumption that you're not experiencing asymmetric routing - that would be a drop to the traffic! Routing must perform symmetrically.

I'd be curious to see what your default rules are. You have the flow:to_server option in all of the rules, which allows suricata to evaluate all rules at essentially the same level until the communication flow is setup.

I like the above approach where an alert rule is put in first to examine the logs - see where the rule is being triggered, but again - you have the flow:to_server (I like to add the ;established).

If your policy is strict order - great! If it's "action order," not good and need to re-configure that. The default rule should be "drop established" vs "drop all." '

One thing to try - un-associate your R53 resolver DNS fw rules first, then try the traffic again, I've had conflicting issues there where I'm blocking all DNS resolution as well. I think this is a simple troubleshooting exercise.

Look at your FW policy action order vs strict order? Default rule at the end, drop established vs drop all? DNS fw?

Take a look at those things, see what you find. I'll follow this post and receive the updates. Thanks!