Your workloads reach most destinations by domain name, but a firewall can only act on what it sees in the traffic. For HTTP and HTTPS, AWS Network Firewall domain rules match the name that the client puts in the request, and the client chooses that name. The connections for protocols such as SSH and SSH File Transfer Protocol (SFTP) don’t carry the domain name. The client uses the name only for the DNS lookup and then connects straight to the IP address that DNS returned. As a result, Network Firewall rules for these protocols have used IP addresses, which change over time. For web and non-web traffic alike, Network Firewall had no view of the answers that your DNS resolver returned, because that shared visibility between DNS and the firewall didn’t exist.

On October 21, 2026, we launched Route 53 Resolved IP Validation for AWS Network Firewall, at no additional charge. Amazon Route 53 Resolver now shares the IP addresses that it returns for each domain name with Network Firewall, and Network Firewall checks each new outbound connection against them. With this launch, you can now filter non-web traffic by domain name, and you can prevent Server Name Indication (SNI) manipulation on TLS traffic without needing to enable TLS inspection.

In this post, we explain how the feature works, show how to turn it on in alert mode, and walk through two common use cases. They’re examples; the same check applies to any outbound traffic that you control by domain name.

Amazon Route 53 Resolver answers DNS queries from resources in your virtual private cloud (VPC) configured to use it, and it’s available by default in every VPC. With this feature, Route 53 Resolver keeps the IP addresses that it returns for each domain name in a resolved IP cache. When a new outbound connection starts, Network Firewall checks the destination address against that cache.

1. The workload asks Route 53 Resolver at 10.0.0.2 for files.partner.example.com.
2. DNS Firewall checks the query first. Domain rules can block or alert on it; an empty rule group lets it through.
3. Route 53 Resolver answers 203.0.113.10 and records the answer in the resolved IP cache.
4. The SFTP connection to 203.0.113.10 on port 22 reaches the Network Firewall endpoint.
5. The policy checks the first packet. The address is in the cache, so the connection continues.
6. The stateful rule passes it, because Route 53 Resolver returned the address for files.partner.example.com.
7. The connection leaves through the NAT gateway and internet gateway.
8. The flow log and alert log record the new fields.

The feature has three parts:

• An Amazon Route 53 Resolver DNS Firewall rule group – It defines the scope. The answers that Route 53 Resolver returns in every VPC associated with this rule group go into the resolved IP cache. The rule group can be empty. Add rules to it and the same rule group also filters the DNS queries themselves, for example, by blocking lookups of known threat domains. Together, DNS Firewall checks the lookup and Network Firewall checks the connection that follows.
• The Network Firewall policy setting – On the first packet of each new connection, before your stateful rules run, Network Firewall checks whether Route 53 Resolver returned the destination address for a domain name. If it did, the connection continues to your stateful rules. If it didn’t, Network Firewall applies the action you chose: Alert, Drop, or Reject.
• Resolved-domain rules – In your stateful rule groups, these rules match a connection by the domain name that its destination address was resolved for, so they work with every protocol. Use the name that your clients look up.

The following diagram shows this architecture.

Figure 1. How Network Firewall checks the SFTP connection from use case 1 against the answers that Route 53 Resolver returned

The policy setting checks every connection, not only web traffic. A connection to an IP address that no client looked up through Route 53 Resolver, such as a hardcoded address, fails the check. If any of your workloads connect straight to IP addresses, add those addresses to Bypass destination validation IP ranges before you enforce. A stateful pass rule doesn’t exempt them because the policy check runs before your rules. The check is per address: when any client in an associated VPC looks up a name, its addresses pass the check for every client in scope in the same Availability Zone. For details, see Resolved IP validation in AWS Network Firewall in the AWS Network Firewall Developer Guide.

To follow along, you need:

• DNS through Amazon Route 53 Resolver – Network Firewall can check only answers that Route 53 Resolver returned. Queries that reach Route 53 Resolver through Resolver endpoints or Resolver forwarding rules count.
• A Route 53 Resolver DNS Firewall rule group associated with the VPCs whose DNS answers Network Firewall should check connections against.
• The policy setting turned on before you add resolved-domain rules – Rules that use domain filtering (the aws_route_53_resolved_domain keyword) need Route 53 Resolved IP Validation turned on in the same firewall policy. Turn the setting on first, in alert mode, then add the rules.
• A supported deployment model – The feature works with distributed deployments, including multiple firewall endpoints, where clients reach a firewall endpoint in their own Availability Zone, and with centralized deployments where the firewall is attached natively to AWS Transit Gateway. If routing sends a client to a firewall endpoint in another Availability Zone, its connections fail the check. To move a centralized deployment to a natively attached firewall, see Why and how to migrate to a Transit Gateway attached AWS Network Firewall.

Start in alert mode because clients cache DNS answers. Network Firewall recognizes only the answers that Route 53 Resolver returns after the DNS Firewall rule group is associated with the VPC and selected in the policy. A client that still uses an answer it cached earlier fails the check until it looks up the name again, usually when its cached record expires. Alert mode lets you see this without blocking anything. Allow about 24 hours in alert mode for clients to refresh their caches.

1. Create a DNS Firewall rule group (it can be empty) and associate it with the VPCs whose DNS answers Network Firewall should check connections against. For the steps, see Creating a rule group and rules.
2. Or, to use a DNS Firewall rule group that you already have, make sure it’s associated with those VPCs and only those. An answer returned in any associated VPC is valid for every client that the firewall checks. Which clients are checked is set by source IP ranges in step 6.
3. In the Amazon Virtual Private Cloud (Amazon VPC) console, under Network Firewall, choose Firewall policies, then choose the policy that your firewall uses. On the Traffic inspection tab, in the Route 53 Resolved IP validation section, choose Edit and select Enable Route 53 Resolved IP validation.
4. For Action, choose Alert. For DNS Firewall rule group, choose the rule group from step 1 or 2.
5. For DNS expiry exception policy, choose what happens to a connection that’s already open when its entry expires from the resolved IP cache. Continue keeps it running, Drop stops it silently, and Reject stops it with a TCP reset. We recommend Continue so that long-running sessions, such as file transfers, aren’t cut off midway. However, choose the option that fits your security requirements.
6. For source IP ranges, list the clients to check. If you don’t set it, Network Firewall checks clients in the firewall’s VPC and in any additional VPCs attached to the firewall. If your clients are in other VPCs, such as spoke VPCs that send traffic to a firewall attached to a transit gateway, enter their CIDR ranges; otherwise, Network Firewall doesn’t check their connections. Add destinations that you allow by IP address to Bypass destination validation IP ranges. Choose Save.

The following screenshot illustrates these steps.

Figure 2. Route 53 Resolved IP Validation turned on in alert mode

In alert mode, Network Firewall doesn’t block a connection that fails the check, and it doesn’t write an alert of its own. It records the result in your flow logs, in the route53_resolved_ip field of each connection. A value of true means Route 53 Resolver returned the destination address for a domain name. A value of false means it didn’t, so enforcement would block the connection. The same field also appears in alert log records that a rule or the policy’s default action writes for the connection. Pass rules don’t write one unless they have the alert; keyword. The DnsUnresolvedFlows metric in Amazon CloudWatch counts the connections that fail the check, and DnsAzUnavailableFlows counts connections from an Availability Zone that doesn’t support the feature. The following alert log record (trimmed, with example values) was written by a default action that alerts, for a connection to an address that Route 53 Resolver returned:

{
  "firewall_name": "egress-firewall",
  "availability_zone": "us-east-1a",
  "event": {
    "event_type": "alert",
    "src_ip": "10.0.1.10",
    "dest_ip": "203.0.113.10",
    "dest_port": 123,
    "proto": "UDP",
    "app_proto": "ntp",
    "route53_resolved_ip": true,
    "verdict": {
      "action": "alert"
    },
    "alert": {
      "action": "allowed",
      "signature_id": 3,
      "signature": "aws:alert_established action"
    }
  }
}

In alert mode, this record is for a TLS connection that presented an allowed domain name but went to an address that Route 53 Resolver didn’t return for it, blocked by the policy’s default action in use case 2:

{
  "firewall_name": "egress-firewall",
  "availability_zone": "us-east-1a",
  "event": {
    "event_type": "alert",
    "src_ip": "10.0.1.10",
    "dest_ip": "198.51.100.7",
    "dest_port": 443,
    "proto": "TCP",
    "app_proto": "tls",
    "tls": {
      "sni": "api.partner.example.com"
    },
    "route53_resolved_ip": false,
    "verdict": {
      "action": "drop"
    },
    "alert": {
      "action": "blocked",
      "signature": "aws:alert_established_app_layer_to_server action"
    }
  }
}

Before you switch Action to Drop or Reject, check that connections that fail the check are ones you expect and that destinations you allow by IP address are in the bypass ranges. Reject sends a TCP reset, so a blocked TCP client fails right away instead of waiting for a timeout. After you enforce, blocked connections appear in your flow logs with route53_resolved_ip as false, not in your alert logs. For the metrics and log fields to watch, see Monitoring and troubleshooting resolved IP validation.

Before this launch, Network Firewall rules for protocols that carry no domain name, such as SFTP, used IP addresses. Now, you can allow them by domain name. In this example, a workload sends files over SFTP to a partner at files.partner.example.com on TCP port 22, and the partner can change the addresses behind that name at any time. The same approach works for SSH, MySQL, and other non-web protocols. You create it as a standard stateful rule. Follow these steps:

1. Under Network Firewall, choose Network Firewall rule groups, then choose Create rule group. Choose Stateful rule group and Standard stateful rule, and choose the rule evaluation order that your policy uses.
2. Choose Add rule. For Protocol, choose TCP. For Destination port, enter 22. Under Domain filtering, enter files.partner.example.com. For Action, choose Pass.
3. Create the rule group, then add it to your firewall policy.

Figure 3. A pass rule for SFTP on TCP port 22, scoped to the partner’s domain name

If you manage rules as code, the equivalent Suricata rule is shown in the following code. It adds the alert; keyword so that the firewall logs allowed connections. The console rule doesn’t add it.

pass tcp any any -> any 22 (alert; msg:"Allow TCP/22 to files.partner.example.com"; aws_route_53_resolved_domain:"files.partner.example.com"; sid:1;)

When the partner moves its server to a new address, the next DNS answer adds it to the resolved IP cache. There’s no IP list to maintain. The cache keeps earlier answers for longer than their DNS time to live (TTL), so the old address can still pass for a while.

With SNI spoofing, a client presents an allowed domain name in its TLS request while it connects to a different server. Preventing that has required TLS inspection, which decrypts the traffic. Route 53 Resolved IP Validation prevents it without TLS inspection. In this example, a workload calls a partner API at api.partner.example.com over HTTPS. TLS traffic on port 443 must reach only the addresses that Route 53 Resolver returned for that name. You create a pass rule in a standard stateful rule group, as in use case 1, and the firewall policy’s default action drops everything that no rule passes. Follow these steps:

1. Under Network Firewall, choose Network Firewall rule groups, and then choose Create rule group. Choose Stateful rule group and Standard stateful rule, then choose Strict order.
2. Choose Add rule. For Protocol, choose TLS. For Destination port, enter 443. Under Domain filtering, enter api.partner.example.com. For Action, choose Pass.
3. Create the rule group, then add it to your firewall policy.
4. In the firewall policy, use strict rule order. For the stateful default actions, choose Application drop established (server-directed only) and Application alert established (server-directed only). The alert action logs what the drop action blocks. For why we recommend these default actions, see Firewall policy configuration in the AWS Security Services Best Practices guide.

Figure 4. A pass rule for TLS on port 443, scoped to the partner’s domain name

If you manage rules as code, the equivalent Suricata rule is:

pass tls any any -> any 443 (aws_route_53_resolved_domain:"api.partner.example.com"; sid:2;)

The pass rule matches the destination address, not the name in the TLS request. TLS traffic on port 443 passes only when Route 53 Resolver returned the destination address for api.partner.example.com. If the partner’s addresses also serve other domain names, such as behind a content delivery network (CDN), those names pass too. To also require the partner’s name in the TLS request, add an exact SNI match to the same rule: tls.sni; content:"api.partner.example.com"; startswith; endswith; nocase;.

Without startswith and endswith, the content match accepts any SNI that contains the name.

A connection that presents the partner’s name but goes to another address doesn’t match the pass rule. If Route 53 Resolver never returned that address, the policy setting’s enforcement action blocks the connection before your rules run. In alert mode, the policy setting lets the connection through to your rules instead, and the stateful default action drops it because the pass rule doesn’t match. Its alert log record shows route53_resolved_ip as false, as in the second example previously. If Route 53 Resolver returned the address for a different domain name, the connection passes the policy check. The stateful default action then drops it because the pass rule doesn’t match, and that record shows route53_resolved_ip as true.

We recommend that you follow these best practices:

• Keep DNS on Route 53 Resolver – Block outbound UDP and TCP port 53 DNS to other resolvers, including DNS over HTTPS (DoH) and DNS over TLS (DoT), on Network Firewall, so that clients don’t bypass the check. Route 53 Resolved IP Validation alone doesn’t do this. If any client looks up a public resolver’s name, such as dns.google, that resolver’s addresses pass the check.
• Keep DNS Firewall rules in those VPCs – Route 53 Resolved IP Validation checks the connections that follow a DNS lookup, not the DNS queries themselves. DNS Firewall blocks lookups of known threat domains with AWS managed domain lists, and its advanced rule groups detect data leaving through DNS queries, such as DNS tunneling.
• Start small – Add domain filtering to a few rules at a time, then add more when the results look clean. For domain allow list patterns, see Allow rules and domain allowlisting.
• Turn on flow and alert logging and detailed monitoring – Connections that fail the resolved IP check show in your flow logs (route53_resolved_ip: false) and in the DnsUnresolvedFlows metric, not in your alert logs. Pass rules without the alert; keyword don’t write an alert log record.

Route 53 Resolved IP Validation is available today in all commercial AWS Regions (Regions other than the AWS GovCloud (US) Regions and the China Regions) where AWS Network Firewall and Amazon Route 53 Resolver DNS Firewall are available, at no additional charge. For the list of Regions, see AWS Capabilities by Region. A DNS Firewall rule group with no rules doesn’t incur DNS Firewall charges. Standard DNS Firewall pricing applies after you add rules. See AWS Network Firewall pricing and Amazon Route 53 pricing.

In this post, we showed you how Route 53 Resolved IP Validation works and how to turn it on in alert mode. Network Firewall now checks each connection’s destination against the IP addresses that Amazon Route 53 Resolver returned for the DNS query. Filtering SFTP, SSH, database, and other non-web traffic by domain name and preventing SNI spoofing without TLS inspection are two common examples of what that makes possible. To get started, turn the feature on in alert mode and review the results before you enforce. For the full walkthrough, see Getting started with resolved IP validation.

We continue to expand the scope of our assurance programs at Amazon Web Services (AWS) and are pleased to announce the successful completion of our first ever Cloud High (PBHH) security assessment with 172 assessed services and features. Completion of this assessment, effective September 18, 2026, makes AWS the first cloud service provider (CSP) in Canada to meet this high security bar and provide assurance to our valued customers. This assessment also reaffirms our commitment to helping public and commercial customers achieve and maintain the highest-grade security standard for workloads with increased sensitivity.

The Cloud High security profile (that is, PBHH) seeks to enhance the integrity and availability of customer organizational workloads that are considered to have an increased level of sensitivity. These are systems that the Government of Canada (GC) and its service providers use to support delivery of services at a national scale or that are determined to be significant for handling sensitive information. The profile is based on the Security and privacy controls and assurance activities catalogue (ITSP.10.033). The Cloud High (PBHH) profile includes all controls and enhancements contained within the Cloud Medium profile (PBMM), with additional controls and enhancements to address higher integrity and availability requirements. The Cloud Medium and Cloud High profiles establish baseline security requirements for cloud services. These services support GC workloads and information processing up to the Protected B level.

As of September 18, 2026, there are a total of 172 AWS services and features that were assessed by the Canadian Centre for Cyber Security (CCCS) under Cloud High security assessment. The assessment covers services and features that are available in both the Canada (Central) and Canada West (Calgary) AWS Regions.

The summary assessment is available through AWS Artifact. You can also learn more about the Cloud High and Medium assessment on the AWS CCCS assessment compliance webpage.

AWS strives to continually bring services into scope of its compliance programs to help you meet your architectural and regulatory needs. Please reach out to your AWS account team if you have questions or feedback about the Cloud High and Medium assessments.

To learn more about our compliance and security programs, refer to AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

The most important work I’ve done in cybersecurity would make for terrible television. There were no countdown clocks and no frantic typing, just a lot of careful reading, a lot of hard conversations, and the occasional quiet moment where everything finally clicked. That’s the part I want to show you this week, because the three people I talked to have built their entire careers on the work that happens off-camera, and it’s the part that decides who lasts in this field.

This is a four-part series following 11 AWS security professionals through the real stories of how they got here and what the work actually looks like. In Part 1: I didn’t plan this, I shared how three of them found their way in, and in Part 2: What even is this job?, we looked at roles most people don’t know exist. This week is about what the day-to-day actually feels like, told through three AWS security professionals whose work rarely makes it into the trailer but is the reason any of it holds together.

Brandon Caldwell, Mgr, Security Engineering

Ask most people to picture an application security engineer at work and they’ll imagine someone hunched over a terminal breaking into systems. Brandon Caldwell‘s actual days (reviewing software while it’s being built so the flaws never ship) look almost nothing like that. He spends them in conversation: sitting with the engineers who built a product, walking through how it works, and asking question after question until he understands it well enough to see where it could break. “This job is at least 50 percent people,” he tells the folks he hires. “You have to people a lot.”

The hardest part of the day isn’t technical, it’s human. Brandon’s team has to hand builders news they don’t want to hear, and he’s blunt with new hires about what that really feels like.

Learning to deliver that message without crushing the person across the table is, in his telling, the actual craft of the job. It’s why he prizes empathy, and why he says the engineers who struggle most in application security are the ones who got into tech specifically to avoid talking to people. The rest of the day is the patient, unglamorous work of reading someone else’s code closely enough to find the one flaw they didn’t know they’d left, then explaining it in a way that lands as help rather than judgment.

That explaining is more than a conversation. So much of security work gets written down: the finding documented so an engineer can act on it, the advisory that tells customers what to do, the policy that sets the bar for everyone who comes after. The ability to write clearly, to turn something messy and technical into a few sentences a reader can actually use, is one of the quiet differentiators as you move up in this field, and it’s a skill worth building long before anyone asks you to.

None of this is where Brandon started. He’s been curious about breaking things since he was a kid hex-editing the game Doom for unlimited ammo, taught himself reverse engineering (taking apart finished software to understand how it works) before it had a name, and spent years as an IT admin and then in incident response at Microsoft back when cybersecurity barely existed as a job title. What pulled him off the breaking side was noticing—after watching the same handful of mistakes scroll past again and again (things like SQL injection and cross-site scripting, two of the most common ways attackers exploit a poorly built website)—that he’d rather help teams avoid the break-in than perform it. Application security, he says, is his natural place.

As for breaking in yourself, Brandon’s advice follows straight from how he spends his days: practice interviewing and asking the right questions and spend real time around builders so you understand what goes into the thing you’re critiquing. When he hires, certifications are the last thing he looks at; he wants to see capture-the-flag competition results (hacking contests where you solve security puzzles to earn points) and public GitHub projects, because those prove you’ve done the work. Build something, break something, and get comfortable talking to the people who build.

Kurt Heath, IT Support Associate

Kurt Heath‘s chosen corner of the work is offensive security: penetration testing (getting paid to legally break into systems to prove where they’re weak) and, eventually, red teaming. The day-to-day of getting good at it is far less cinematic than the label suggests. It’s hours of hands-on practice against deliberately vulnerable targets, reading about a technique and then trying it until it works, and the slow accumulation of the layers the job actually rests on: operating systems, networking, software development, and security fundamentals, all applied at once. He’s the first to say pen testing is “the sexy thing” that gets advertised, and the first to warn that it shouldn’t be anyone’s first stop, because of how much quiet groundwork sits underneath it.

A big part of his real workday now is deciding how, and how much, to lean on AI. Kurt treats it as a tool rather than a crutch: he uses it as a coding assistant when he has to work in an unfamiliar language, and to sort through large volumes of information quickly, but he won’t let it think for him. He still fills out forms like this blog’s questionnaire by hand, keeping a personal touch on his own work, and he’s wary of letting AI pull the trigger during an engagement, since an overzealous tool can act on a network however it sees fit, cause unintended operational damage, or wander out of scope and create a legal problem. The way he sees it, security is fundamentally a human problem: automation keeps getting better at the systematic parts, but thinking outside the box the way an attacker does stays stubbornly human.

How Kurt got here matters less to the day-to-day than how he keeps going, but it’s worth knowing that he’s largely self-taught. After a community college program didn’t work out, he taught himself from scratch, finishing shifts at an auto plant and then spending nights with YouTube and a search bar learning how computers and networks actually worked. The hardest part, he told me, was self-motivation, and what carried him through was a mix of sheer want and, eventually, other people: the friends and community he found in Discord servers, security podcasts, and interest channels who helped him turn raw drive into real focus. He even got a tattoo as a reminder that there is no plan B.

“There is no other option. There’s no what if. This is it. This is life now, and I’ll figure it out some way, somehow, no matter how long it takes.” – Kurt Heath

---

If you’re drawn to the same offensive work, Kurt’s advice is to resist starting there. Build the foundation first, often through a role like a security operations center, join the communities where people are learning in the open, and let the flashier work come after the groundwork is solid. Progress in this field—in his experience—is measured less by the title you land than by how much you grow and who you grow alongside.

The comfort lock

Seth Jeacopello, Mgr, Security Engineer

Seth works in application security too, but if Brandon’s days are mostly about people, Seth’s are mostly about code, which makes the two of them a useful picture of how differently the same job can look. When Seth Jeacopello gets stuck on a hard problem, he doesn’t stare at it harder, he picks up a lock. An actual physical lock with pins and tumblers, because he’s a serious lock-picking hobbyist, and over the years he’s learned that the best response to hitting a wall is to set the problem down and pick what he calls a comfort lock, one he knows well and can open easily. It isn’t about the lock; it’s about giving his brain a small win so he can return to the hard thing with fresh eyes.

The comfort lock exists because Seth’s actual day-to-day is easy to get lost in. In application security, a big part of the job is reading enormous amounts of someone else’s code looking for the one flaw that matters, and as a lifelong developer he genuinely loves reading code, which is exactly what makes it a trap. He described the pull of it to me: you convince yourself the vulnerability is just behind the next function, and the next, and suddenly two days are gone. The skill he’s spent decades sharpening isn’t finding things, it’s knowing when deep enough is deep enough and when to step back, which is where the lock comes in. After 26 years, the meta-skill of managing his own attention is as much a part of the craft as anything technical.

That longevity goes back a long way. Around 1999, still in his teens, he landed a software quality assurance internship, was hired as a developer by 17, and gravitated toward the security-flavored work from the start before moving into network security tooling, rising to chief architect and then chief technology officer along the way.

“We’re like three or four guys off the street coming in with a product, and this huge company was like, yeah, you three, go for it. That was probably one of the coolest things.” – Seth Jeacopello

---

His advice for building the instincts the daily work demands is refreshingly concrete: set up a deliberately vulnerable practice machine, break into it, and then go read the logs it generated, so you learn not just how an attack works but what it looks like from the defender’s side. That single exercise builds both the offensive and the investigative muscle at once, and it’s the kind of patient, repeatable practice that the day-to-day of this field actually rewards.

The thread

There’s a version of cybersecurity that makes for great television, fast-paced and full of eureka moments, and those moments do exist. But the three people I talked to this week live in a different version of the field, one built on patience, repetition, and a kind of stubborn care that doesn’t photograph well. For Brandon, the real work is the hard, human conversation of telling a builder their work is flawed without making an enemy of them. For Kurt, it’s the unglamorous hours of hands-on practice and the discipline to use AI as a tool without letting it think for him. For Seth, it’s reading one more page of code and knowing when to stop, with a comfort lock on the desk for when he can’t.

None of that makes a great action sequence, but all of it is what a security career actually looks like, and the good news for anyone starting out is that these are learnable habits, not inborn talent. Notice how much of the real work is human: empathy, patience, judgment, and knowing how your own mind works. The analytical, interpersonal, and self-management skills you already have are not a consolation prize, they are part of the job. If you want to begin building the rest, here are a few places to start:

• TryHackMe and Hack The Box let you stand up deliberately vulnerable machines, break in, and study what you triggered, exactly the exercise Seth recommends
• The OWASP Top 10 explains the most common application security flaws, including the ones Brandon saw on repeat
• The OWASP Cheat Sheet Series turns those flaws into practical, task-level guidance on how to build and review software securely; the daily bread of Brandon’s and Seth’s work
• The Darknet Diaries podcast tells the human stories behind real security incidents, and it’s a good way to hear what the work actually feels like

And if you want to build cloud security skills specifically, AWS has free and hands-on resources to help you start:

• AWS Skill Builder offers more than 1,000 free self-paced courses, including security learning plans you can start today
• AWS Builder Labs lets you practice in a real AWS console on hands-on security labs, the stand-it-up-and-try-it approach Seth recommends

In Part 4: What I’d tell myself, we close the series with the advice and hard-won lessons these professionals would hand to someone just starting out.

Doing the work behind the work? These three want you to know it counts. Share your story on LinkedIn!