By using AWS re:Post, you agree to the Terms of Use

Questions tagged with Amazon VPC

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Network Firewall shows "aws:alert_strict action" when it set with Strict Order stateful engine option.

Hello, I'm using AWS Network Firewall. Firstly, I tried to use AWS Managed Rules and Allow Domain List custom rule with default action order. From my understanding, the default action order is Pass -> Drop -> Alert. Then, I tried to test download files from allowed domain list it always pass because the domain is allowed. The **ThreatSignaturesMalwareCoinmining** will not perform any actions. Am I correct? So, I'm trying to change from default action order to strict order. The default actions are drop:all and alert:all. I expected that the network firewall will process my rule groups by priority and rules in each rule group by order. I copied Suricata context from AWS Managed Rule and created new rule group as shown in pictures. ![Enter image description here](/media/postImages/original/IMT6cNSaDhTbGF4Ym0R7I1sQ) ![Enter image description here](/media/postImages/original/IMQKpehfhvQdCQLbXZVvTS4g) My example allowed domain are AWS domains. pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; dotprefix; content:".amazonaws.com"; endswith; msg:"Allow HTTP traffic to .amazonaws.com"; flow:to_server, established; sid:1000101; rev:1;) pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; dotprefix; content:".amazonaws.com"; endswith; msg:"Allow TLS traffic to .amazonaws.com"; flow:to_server, established; sid:1000102; rev:1;) Then, I added these rules into my firewall policy and I found that it stills block the traffic to .amazonaws.com. ``` { "firewall_name": "inspector", "availability_zone": "ap-southeast-1a", "event_timestamp": "1663828976", "event": { "timestamp": "2022-09-22T06:42:56.727635+0000", "flow_id": 1066945104298575, "event_type": "alert", "src_ip": "10.x.x.x", "src_port": 23602, "dest_ip": "3.0.186.102", "dest_port": 443, "proto": "TCP", "alert": { "action": "blocked", "signature_id": 2, "rev": 0, "signature": "aws:alert_strict action", "category": "", "severity": 3 } } } ``` I checked 3.0.186.102 is own by AWS, ec2-xxx.amazonaws.com. Why the network firewall always block the requests to AWS domain?
4
answers
0
votes
46
views
asked 11 days ago

Lambda random long execution while running QLDB query

I have a lambda triggered by a SQS FIFO queue when there are messages on this queue. Basically this lambda is getting the message from the queue and connecting to QLDB through a VPC endpoint in order to run a simple SELECT query and a subsequent INSERT query. The table selected by the query has a index for the field used in the where condition. Flow (all the services are running "inside" a VPC): `SQS -> Lambda -> VPC interface endpoint -> QLDB` Query SELECT: `SELECT FIELD1, FIELD2 FROM TABLE1 WHERE FIELD3 = "ABCDE"` Query INSERT: `INSERT INTO TABLE1 .....` This lambda is using a shared connection/session on QLDB and this is how I'm connecting to it: ``` import { QldbDriver, RetryConfig } from 'amazon-qldb-driver-nodejs' let driverQldb: QldbDriver const ledgerName = 'MyLedger' export function connectQLDB(): QldbDriver { if ( !driverQldb ) { const retryLimit = 4 const retryConfig = new RetryConfig(retryLimit) const maxConcurrentTransactions = 1500 driverQldb = new QldbDriver(ledgerName, {}, maxConcurrentTransactions, retryConfig) } return driverQldb } ``` When I run a load test that simulates around 200 requests/messages per second to that lambda in a time interval of 15 minutes, I'm starting facing a random long execution for that lambda while running the queries on QLDB (mainly the SELECT query). Sometimes the same query retrieves data around 100ms and sometimes it takes more than 40 seconds which results in lambda timeouts. I have changed lambda timeout to 1 minute but this is not the best approch and sometimes it is not enough too. The VPC endpoint metrics are showing around 250 active connections and 1000 new connections during this load test execution. Is there any QLDB metric that could help to identify the root cause of this behavior? Could it be related to some QLDB limitation (like the 1500 active sessions described here: https://docs.aws.amazon.com/qldb/latest/developerguide/limits.html#limits.default) or something related to concurrency read/write iops?
1
answers
0
votes
53
views
asked 13 days ago