How Do You Detect Unsolicited Inbound Traffic in NAT Gateway Flow Logs?
Determine a strategy to improve security.
Determine a strategy to improve overall operational excellence.
Answer
Correct answer: D — Use CloudWatch Logs to query NAT gateway and instance ENIs for dstAddr like 198.51.100.2 and srcAddr like 203.0 to check whether the VPC initiated the flow.
A company has VPC flow logs enabled for Its NAT gateway. The company is seeing Action = ACCEPT for inbound traffic that comes from public IP address 198.51.100.2 destined for a private Amazon EC2 instance. A solutions architect must determine whether the traffic represents unsolicited inbound connections from the internet. The first two octets of the VPC CIDR block are 203.0. Which set of steps should the solutions architect take to meet these requirements?
Community Insight
Testing whether NAT gateway inbound traffic is unsolicited requires finding the corresponding outbound flow from the VPC CIDR to the public IP; the trap is re-querying the already-visible inbound record (option B) or using CloudTrail instead of CloudWatch Logs.
VPC Flow Logs for a NAT gateway are analyzed in Amazon CloudWatch Logs, not CloudTrail, to determine whether inbound traffic from 198.51.100.2 was solicited. The page establishes that option D is correct because it queries the reverse flow from the 203.0 VPC CIDR back to the public IP to see whether the instance initiated the connection.
The most common wrong choice is B: it opens CloudWatch and filters on the exact inbound tuple already observed, but that only restates the suspicious traffic and cannot prove whether the VPC contacted 198.51.100.2 first.
Community Discussion (77 comments)
dathv
👍 1
Selected: D
we have to check if this is unsolicited connection. the only way to check that is if there was no initial request from vpc to destination. If there was, the accept in the flow log is for return traffic. if there is none, we can safely assume it is unsolicited request. you would see all unsolicited requests as accepted on flow logs and then they will get dropped.
venco
👍 1
Selected: D
Answer D tells you what you already know (from the question), that outside traffic came in. What we need to know is whether there was a previous TCP handshake - initiated by an inside host (in the 203.0 block)
venco
👍 1
Sorry, typo in my post! "B" tells you what you already know. D is correct. (Got distracted by the very strange CIDR block)
braveheart22
👍 1
Selected: D
D is correct. Why CloudWatch, not CloudTrail? VPC Flow Logs are commonly delivered to: Amazon CloudWatch Logs and Amazon S3. They are not queried through CloudTrail. So, A and C are incorrect because they use CloudTrail. Option D filters: destination like 198.51.100.2 — catches outbound flows toward that IP source like 203.0 — catches flows originating from within the VPC
d8945a1
👍 1
Selected: D
The key is to determine whether the traffic from public IP 198.51.100.2 was actually unsolicited inbound traffic, or whether it was return traffic from an outbound connection initiated by the private EC2 instance through the NAT gateway.
vinalt
👍 1
Selected: D
we have to check if this is unsolicited connection. the only way to check that is if there was no initial request from vpc to destination. If there was, the accept in the flow log is for return traffic. if there is none, we can safely assume it is unsolicited request. you would see all unsolicited requests as accepted on flow logs and then they will get dropped.
princajen
👍 1
Selected: B
Use Amazon CloudWatch Logs to query VPC flow logs (not CloudTrail). To verify if a public IP (198.51.100.2) initiated unsolicited inbound traffic, filter for: source = 198.51.100.2 destination = internal CIDR 203.0.x.x This shows whether the traffic originated externally, and whether the internal host initiated it or not.
papan83
👍 7
Selected: D
Step-by-Step Approach: You already have this log entry: srcaddr = 198.51.100.2 dstaddr = 203.0.x.x action = ACCEPT Now, query CloudWatch Logs for the reverse flow: srcaddr = 203.0.x.x (your EC2 instance) dstaddr = 198.51.100.2 (the public IP) If you find outbound traffic from your instance to the public IP before the inbound traffic, then the connection is solicited (i.e. it's a reply). If you do not find any outbound flow to that public IP, then the traffic is unsolicited — a potentially unexpected or malicious inbound attempt that should have been blocked.
BennyMao
👍 2
Selected: D
The NAT gateway allows outbound internet traffic from private instances but does not accept unsolicited inbound connections. If 198.51.100.2 is contacting the private instance, we need to determine if this is a response to an existing outbound request from the private instance.
grumpysloth
👍 1
Selected: D
we need to check if the request starts from ec2 instances outbound, not the other way round.
youonebe
👍 3
Correct answer is D. This is for NAT traffic analysis, so the focus is outbound. VPC Flow Logs are published to CloudWatch Logs, not CloudTrail1. This immediately eliminates options A and C. To determine if the traffic is unsolicited inbound connections: We need to check if the private EC2 instance (starting with 203.0) initiated the connection to 198.51.100.2 If the source IP is from the VPC (203.0) and the destination is 198.51.100.2, this indicates the connection was initiated from inside the VPC This would mean the ACCEPT traffic is a response to an outbound request, not unsolicited inbound traffic.
tural_nasirov
👍 1
Selected: B
The answer is B. This is not about an IP but about a port. If the packet from outside to inside has the source port which is well known and the destination port dynamic, it means that the connection was initiated from inside, if the packet from outside to inside has a source port dynamic and destination port well known, it means that the traffic was originated from outside :)
sashenka
👍 3
Selected: D
Why Option B is Problematic: // Example CloudWatch Logs Insights Query for Option B fields @timestamp, sourceAddress, destinationAddress, action, bytes | filter destinationAddress like "203.0" | filter sourceAddress like "198.51.100.2" | stats sum(bytes) by sourceAddress, destinationAddress 1. Incorrect Traffic Direction - It looks for traffic where source = 198.51.100.2 (internet) and destination = 203.0.x.x (VPC) This only shows successful inbound connections (ACCEPT) It doesn't reveal whether these connections were solicited or unsolicited 2. Missing Context - Doesn't show the initial outbound connection that would indicate a solicited response - Cannot differentiate between legitimate responses and actual unsolicited connections - Lacks the temporal relationship between outbound and inbound flows
sashenka
👍 2
Better Approach (Option D) sql // Example CloudWatch Logs Insights Query for Option D fields @timestamp, sourceAddress, destinationAddress, action, bytes | filter sourceAddress like "203.0" | filter destinationAddress like "198.51.100.2" | stats sum(bytes) by sourceAddress, destinationAddress This query would: Show outbound traffic from VPC to the internet Help establish if the private instance initiated communication Allow correlation between outbound requests and inbound responses Key Concept With NAT gateway connections: Legitimate traffic follows a request-response pattern Outbound request must exist before inbound response Looking only at inbound traffic (Option B) misses this crucial relationship Therefore, Option D provides the necessary visibility to determine if the inbound connections were truly unsolicited by examining the outbound traffic first.
sammyhaj
👍 3
D, we need to see if the internal origin was first used
NirvanaSNM
👍 1
Selected: B
destination address set as "like 203.0" and the source address set as "like 198.51.100.2"
mns0173
👍 2
Of course it is D. What useful info will you get from B? You need to check original request which in case of NAT is always EC2, not something in the internet.
Helpnosense
👍 1
Selected: B
I vote B. Because the network traffic to check is unsolicited inbound connection. IT is initiated from the internet to internal EC2. The source is public IP address and the target is internal IP.
higashikumi
👍 1
Selected: B
To determine whether the traffic represents unsolicited inbound connections from the internet, use the Amazon CloudWatch console. Select the log group that contains the NAT gateway’s elastic network interface and the private instance’s elastic network interface. Run a query to filter with the destination address set as “like 203.0” and the source address set as “like 198.51.100.2”. This approach helps you analyze the VPC flow logs to identify if the inbound traffic to the private EC2 instance is expected return traffic or unsolicited. The stats command can be used to filter the sum of bytes transferred by the source address and the destination address, providing insight into the traffic patterns and ensuring network security.
Vongolatt
👍 3
Selected: D
the solution architect want to check if it's unsolicited traffic or not, so we need to check the if the request is sent by us. which means 198.51.100.2 should be the destination.
gofavad926
👍 2
Selected: B
B, CloudWatch & destination address 203.0
ajeeshb
👍 3
Selected: D
The question is "Solutions architect must determine whether the traffic represents unsolicited inbound connections from the internet". The NAT gateway does not allow any inbound traffic from an internet other than response to a traffic it sent out to internet which came from a VPC resource (eg, EC2). So to find out if the inbound traffic to NAT Gateway from internet IP 198.51.100.2 is unsolicit or not, check the vpc flowlog to see if there was an original request from source IP 203.0 to destination 198.51.100.2. This is what option D says.
hogtrough
👍 1
I should clarify that NAT Gateway is considered egress only so while it technically prevents incoming traffic it's only use is for outbound traffic.
8608f25
👍 2
Selected: B
Option B is correct because VPC flow logs are stored in Amazon CloudWatch Logs. Analyzing these logs in CloudWatch allows you to filter and examine specific traffic patterns, such as traffic coming from a public IP address to a private instance. The query specified in this option correctly aims to identify traffic from the public IP (198.51.100.2) to the private IP range of the VPC (beginning with 203.0), which aligns with the requirement to investigate unsolicited inbound connections.
master9
👍 3
Selected: D
Action = ACCEPT for inbound traffic that comes from public IP address 198.51.100.2 --> Destination
cox1960
👍 5
B is what "the company is seeing", so D to see if it was first initiated from EC2.
hogtrough
👍 1
NAT Gateway does not stop incoming traffic, it simply allows to reach outside. Regardless, NAT Gateway is irrelevant to the answer of which is the source IP and which is the destination IP. "Inbound traffic from" by itself suggests that it's the source IP.
bjexamprep
👍 2
I would say this question is wrong, even we ignore the 203.0 is a public IP. Both B and D can do the job. With B: if the return value is bigger than 0, that means the traffic was initiated from internal so that NAT GW wouldn't drop that traffic. While, if the return is 0, that means the traffic was dropped by NAT after ACCEPTed, which means it was not initiated from internal. With D: if the return value is bigger than 0, obviously the traffic was initiated from internal. If the return value is 0, that means the traffic was initiated from internet.
ninomfr64
👍 1
You need first to query traffic from public IP to private IP, check if the NAT Gateway is the only private IP. If not then you query traffic (from private IP to public IP) OR (from public IP to private IP) and this will show bi-directional traffic allowing you to determine whether the private instance or external public IP address is the initiator. Thus B and not D
severlight
👍 3
Selected: B
see kiran15789's answer
AMohanty
👍 1
D At NAT GW VPC flow logs will destination be VPC Private IP or will it be NAT GW IP
study_aws1
👍 2
I was inclined towards Reason #2 in https://repost.aws/knowledge-center/vpc-analyze-inbound-traffic-nat-gateway. However, the striking point is the VPC CIDR 203.0.... which is not a private addressing and not sure if we require a NAT gateway here at all for translation & check if the traffic was initiated through NAT gateway. Does the definition of unsolicited connection means any inbound connection other than the traffic initiated from VPC via NAT gateway will not be considered as solicited. Tough one from the unclear definition in the question, it would be Reason 1 (Option B) if the traffic is mentioned as dropped in the question but needs to be analyzed for whether this is unsolicited. Or if question states inbound traffic is not permitted, but still it is seen and needs to be analyzed then D). Again, point to be noted is why outbound traffic from '203.0...' needs to go via NAT gateway.
ggrodskiy
👍 2
Correct D. You need to open the Amazon CloudWatch console, select the log group that contains the NAT gateway's elastic network interface and the private instance's elastic network interface, run a query to filter with the destination address set as "like 198.51.100.2" and the source address set as "like 203.0", and run the stats command to filter the sum of bytes transferred by the source address and the destination address.
Jonalb
👍 2
Selected: B
bbbbbbbbbbb
NikkyDicky
👍 3
Selected: D
D. see filter expression in https://repost.aws/knowledge-center/vpc-analyze-inbound-traffic-nat-gateway, reason #2
hexie
👍 6
Selected: B
B. No clue of why you guys that voted D are convinced. Destination will be your VPC octets, source is the IP that is making the requests.
swadeey
👍 1
But isn't Nat gateway to stop incoming traffic and allow ec2 to reach outside. One was external traffic. So when we filter from AWS prespectivr source is our machine and destination is outside as that is functioning of NAT Gateway
Maria2023
👍 5
I have the feeling that this question is missing the "Choose 2" option. Ideally, I would run both queries (B and D) to see if the outbound matches the inbound
SkyZeroZx
👍 2
Selected: B
we wanna check if its unsolicited traffic or not, so we gotta check if its a response for a outbound connection we made
ZK000001qws
👍 3
Selected: B
The ask is "A solutions architect must determine whether the traffic represents unsolicited inbound connections from the internet". inbound connections from the internet - if we are to check the inbound connection, wouldn't the source be internet IP and destination be VPC? Thus I choose B too. If it was outbound, initiated from VPC then it would make sense for D.
swadeey
👍 1
But how Nat gateway send traffic to ec2 because ec2 will be in private subnet with private ips and Nat gateway just allow Nat translation for ec2 with private ip to reach to Internet via public natted Ip.
johnballs221
👍 4
Selected: D
we wanna check if its unsolicited traffic or not, so we gotta check if its a response for a outbound connection we made
andreitugui
👍 1
Selected: B
So simple, CloudWatch logs to filter them(exclude aws cloudtrail), you need to check Inbound traffic to the vpc DESTINATION cidr 203.0 from SOURCE public ip 198.50.
rbm2023
👍 1
Selected: B
This article https://repost.aws/knowledge-center/vpc-analyze-inbound-traffic-nat-gateway Talks about two reasons why a NAT Gateway would show inbound traffic from Public IP address to a private instance. Reason 1 - Inbound internet traffic is permitted by your security group or network access control lists (ACL) - Check if the traffic is UNSOLICITED. Run query: filter (dstAddr like 'xxx.xxx' and srcAddr like 'public IP') | stats sum(bytes) as bytesTransferred by srcAddr, dstAddr | limit 10
rbm2023
👍 1
Query results show traffic on the NAT gateway private IP from the public IP, but not traffic on other private IPs in the VPC. These results confirm that the incoming traffic was unsolicited. However, if you do see traffic on the private instance's IP, then follow the steps under Reason #2. Reason 2 - Traffic to the public IP was initiated from a private instance. The question DOES NOT state which reason it would be except for the UNSOLICITED word in question. I am choosing B for this one.
Maria2023
👍 7
Selected: D
Initially I went for B but when I saw the answer and read the documentation I am going for D due to the word "unsolicited" traffic. That for me means that we need to check if it's a return traffic, requested by a machine in the VPC. So we check whether any instance called that IP. B would more be for the associate exam
Wobs1
👍 1
It's the other way around. The traffic would be solicited if it was initiated from the EC2 instance.
johnballs221
👍 1
My thoughts exactly
Sarutobi
👍 1
Is this question even correct? It is possible, but what is the point of using a NAT-GW if the two IP addresses are public? Another issue is if you are initiating the traffic from the Internet, you cannot reach an EC2 instance behind a NAT-GW, because that instance has a private address. In other words, traffic is always Ec2->NAT-GW->Internet. Under normal circumstances, traffic through the NAT-GW always has a source address Private and a destination address Public. Obviously, the reply to this packet flips the source and destination.
vandergun
👍 1
Selected: D
I vote for D
Jay_2pt0_1
👍 1
I'm curious as to why. Wouldn't the source be the public IP (that we want to research) and the destination our VPC?
mfsec
👍 5
Selected: B
Option B is better than option D because it filters the logs based on the source address "like 198.51.100.2" (the public IP address) and the destination address "like 203.0" (which corresponds to the VPC CIDR block). By analyzing the traffic between these addresses, you can determine whether the traffic represents unsolicited inbound connections from the internet.
taer
👍 2
Selected: B
B is correct
zejou1
👍 3
Selected: B
B is the better option -> we need to understand why and which IPs this is hitting. If it is being allowed through, then we can identify the actual Private internal VPC that may have a bad inbound security group allowing connectivity. Once that is identified, we could reverse (or add an 'or') to see all inbound and outbound traffic between the two. Identify the actual flow first before flipping it hence statement: Query results show traffic on the NAT gateway private IP from the public IP, but not traffic on other private IPs in the VPC. These results confirm that the incoming traffic was unsolicited. However, if you do see traffic on the private instance's IP, then follow the steps under Reason #2. (this is more security analytics/traffic log review)
hobokabobo
👍 2
Selected: B
source is internet address
kiran15789
👍 23
Selected: B
https://aws.amazon.com/premiumsupport/knowledge-center/vpc-analyze-inbound-traffic-nat-gateway/ Refer Reason 1 Run the query below. filter (dstAddr like 'xxx.xxx' and srcAddr like 'public IP') | stats sum(bytes) as bytesTransferred by srcAddr, dstAddr | limit 10 Note: You can use just the first two octets in the search filter to analyze all network interfaces in the VPC. In the example above, replace xxx.xxx with the first two octets of your VPC classless inter-domain routing (CIDR). Also, replace public IP with the public IP that you're seeing in the VPC flow log entry. Query results show traffic on the NAT gateway private IP from the public IP, but not traffic on other private IPs in the VPC. These results confirm that the incoming traffic was unsolicited. However, if you do see traffic on the private instance's IP, then follow the steps under Reason #2.
sashenka
👍 1
It has to be D as it only includes unsolicited traffic. Option B includes both.
sashenka
👍 1
To determine whether the traffic represents unsolicited inbound connections from the internet, use the Amazon CloudWatch console. Select the log group that contains the NAT gateway’s elastic network interface and the private instance’s elastic network interface. Run a query to filter with the destination address set as “like 203.0” and the source address set as “like 198.51.100.2”. This approach helps you analyze the VPC flow logs to identify if the inbound traffic to the private EC2 instance is expected return traffic or unsolicited. The stats command can be used to filter the sum of bytes transferred by the source address and the destination address, providing insight into the traffic patterns and ensuring network security.
zejou1
👍 2
For those that are choosing D - this is why D is incorrect and needs to be B
saurabh1805
👍 2
Selected: B
for me correct answer is B
monkeyfish
👍 2
Selected: B
B because: destination address set as "like 203.0" source address set as "like 198.51.100.2"
c73bf38
👍 1
Selected: D
Option D is the correct answer because Amazon CloudWatch Logs Insights can be used to filter the sum of bytes transferred by the source address and the destination address. The solution architect should open the CloudWatch console, select the log group that contains the NAT gateway's elastic network interface and the private instance's elastic network interface, and then run a query to filter with the destination address set as "like 198.51.100.2" and the source address set as "like 203.0". Finally, run the stats command to filter the sum of bytes transferred by the source address and the destination address.
hobokabobo
👍 1
No I think you are right. It talks about inbound traffic. Meaning source is the public IP. If this is even possible in reality: don't know. Question does say inbound - so....
c73bf38
👍 1
VPC cidr is SRC "203.0" DST = 195.51.100.2 which is public address keep in mind you're tracing the route from the VPC SRC (203.0.) to the Public internet DST 195.51.100.2 using cloudwatch.
rtgfdv3
👍 1
my bad is B Note: You can use just the first two octets in the search filter to analyze all network interfaces in the VPC. In the example above, replace xxx.xxx with the first two octets of your VPC classless inter-domain routing (CIDR). Also, replace public IP with the public IP that you're seeing in the VPC flow log entry.
rtgfdv3
👍 1
looks like i am wrong should be D filter (dstAddr like 'xxx.xxx' and srcAddr like 'public IP') | stats sum(bytes) as bytesTransferred by srcAddr, dstAddr | limit 10 Note: You can use just the first two octets in the search filter to analyze all network interfaces in the VPC. In the example above, replace xxx.xxx with the first two octets of your VPC classless inter-domain routing (CIDR). Also, replace public IP with the public IP that you're seeing in the VPC flow log entry.
getsat0024
👍 3
It is B Reference:https://aws.amazon.com/premiumsupport/knowledge-center/vpc-analyze-inbound-traffic-nat-gateway/
rtgfdv3
👍 1
Based in this is D. filter (dstAddr like 'xxx.xxx' and srcAddr like 'public IP') | stats sum(bytes) as bytesTransferred by srcAddr, dstAddr | limit 10
spd
👍 2
Selected: B
I think B - SOurce public IP
oatif
👍 2
Selected: B
B is correct.
moota
👍 3
Selected: D
Trick question. A NAT Gateway is not supposed to accept incoming traffic. There might be a security issue here.
rtgfdv3
👍 1
https://aws.amazon.com/premiumsupport/knowledge-center/vpc-analyze-inbound-traffic-nat-gateway/ basically it accepts the traffic, then dopt it. the idea is check if the sum is more than 0 from NAT to Public Destination
Untamables
👍 3
Selected: D
This is a trick question. 'Action = ACCEPT' response is sent from private EC2 instances (203.0.x.x) to the public IP address (198.51.100.2) via the NAT Gateway. The NAT Gateway can catch only this outbound traffic because the relevant inbound traffic does not pass through the NAT Gateway.
zozza2023
👍 2
should be B no? as the source =198.51.100.2. and dest =203.0 I think D is the inverse
vsk12
👍 23
I would go with option B. Source will be public IP like 198.51.100.2.
masetromain
👍 5
Selected: D
The correct answer is D. Open the Amazon CloudWatch console. Select the log group that contains the NAT gateway's elastic network interface and the private instance's elastic network interface. Run a query to filter with the destination address set as "like 198.51.100.2" and the source address set as "like 203.0". Run the stats command to filter the sum of bytes transferred by the source address and the destination address. This set of steps will allow the solutions architect to determine whether the inbound traffic coming from the public IP address 198.51.100.2 is unsolicited, by filtering the VPC flow logs to show the traffic that is going to the private Amazon EC2 instance, and then checking if the traffic is coming from within the VPC CIDR block (203.0) or from outside of it (198.51.100.2). By using Amazon CloudWatch and filtering the logs with the specified IP addresses, the architect can quickly and efficiently identify any unsolicited traffic.
masetromain
👍 2
The other options are not correct because they are not using the correct service (CloudTrail instead of CloudWatch) or not filtering the logs correctly with the specified IP addresses and the desired information is not available.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D is the only choice that both uses the correct log destination and checks the direction needed to answer the question. VPC Flow Logs are stored in Amazon CloudWatch Logs, so the architect should open the CloudWatch console, select the log group for the NAT gateway ENI and the private EC2 ENI, and query for dstAddr like 198.51.100.2 with srcAddr like 203.0. If that reverse flow exists before the inbound ACCEPT record, the traffic is a response to an outbound connection initiated by the VPC; if it does not exist, the inbound connection is more likely unsolicited. The stats command summing bytes by srcAddr and dstAddr is the documented way to compare the two directions.Why the Other Options Are Wrong
Options A and C send the architect to AWS CloudTrail, which records API activity and cannot contain NAT gateway packet-flow records; that alone eliminates them. Options B and D correctly use CloudWatch, but B filters with destination 203.0 and source 198.51.100.2, which is the same inbound record the company already sees. B can confirm that the traffic exists, but it cannot show whether the VPC contacted 198.51.100.2 first, so it does not resolve the "unsolicited" question. C also reverses the useful direction and uses CloudTrail.Community Comment Notes
Several learners were split between B and D. Maria2023 initially chose B but changed to D because the word "unsolicited" requires checking "if it's a return traffic, requested by a machine in the VPC"; cox1960 made the same point, saying B is what the company already sees and D is needed "to see if it was first initiated from EC2". johnballs221 similarly said the goal is to check whether the inbound flow is a response to an outbound connection. The B-leaning comments, such as kiran15789's query using dstAddr like the VPC prefix and srcAddr like the public IP, describe the visible inbound record but do not establish whether the connection was solicited.Official Reference
Exam Strategy
Eliminate CloudTrail immediately whenever the stem asks about VPC Flow Logs or packet-level traffic, because CloudTrail records AWS API calls, not flow records. Then decide which direction of the flow proves the point: for unsolicited inbound, look for the VPC-initiated outbound flow, not the inbound record that prompted the investigation.
Frequently Asked Questions
Why is CloudTrail wrong for analyzing NAT gateway flow logs?
VPC Flow Logs are delivered to CloudWatch Logs (or S3/Firehose), not CloudTrail, which records AWS API activity rather than packet flows.
Why query dstAddr like 198.51.100.2 instead of the inbound record already seen?
The visible inbound record only shows the public IP sending traffic; the reverse flow with dstAddr 198.51.100.2 and srcAddr 203.0 shows whether the EC2 instance initiated the connection first.
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →