First 90 Days Checklist for New Hire Security Engineer in AWS Infrastructure

First 90 Days Checklist for New Hire Security Engineer in AWS Infrastructure

TL;DR

A new AWS security engineer must secure identity, harden the network, instrument services, demonstrate measurable risk reduction, and align compensation expectations within 90 days. The judgment: skip generic onboarding and focus on three concrete pillars—Access, Infrastructure, and Impact—to earn trust and position for senior growth.

Who This Is For

The guide targets engineers hired into a mid‑level security role (typically $130,000–$170,000 base) at a large cloud‑focused organization, who have 0–2 years of AWS experience, and who must prove value before a formal 90‑day review. The reader is comfortable with the AWS console, knows basic IAM, and is seeking a no‑fluff roadmap that translates directly into managerial credibility.

How should I prioritize access reviews in the first 30 days?

The answer: focus on privileged IAM roles, cross‑account trust policies, and service‑linked permissions before any other audit. In my first week at a Fortune‑500 cloud division, the hiring manager objected when I wanted to start with VPC flow logs. The debrief later that afternoon clarified that the manager’s real concern was “who can break the chain of trust.” I spent day 2–5 mapping every admin‑level role to business owners, then ran a risk‑scoring script that flagged 12 over‑privileged policies. The judgment: not “review everything,” but “triage by privilege level.”

The insight layer is a simple three‑step Access‑Triaging Framework: (1) enumerate all IAM entities, (2) score each by privilege weight (admin = 5, power‑user = 3, read‑only = 1), (3) remediate highest‑scoring items first. This framework converts vague “least‑privilege” talk into a concrete action list that senior leadership can measure. By day 15, the team reduced privileged policy count by 28 % and documented the change in the internal risk register, a metric that survived the 90‑day review.

What immediate network hardening tasks deliver the strongest risk reduction?

The answer: apply security groups tightening, enable VPC flow logs, and enforce AWS Shield Advanced on exposed endpoints within the first month. During a Q2 debrief, the senior security manager pushed back on my proposal to launch a full‑scale network scan, arguing that “scans are noisy and can trigger alarms.” The judgment was not “run every scanner,” but “targeted hardening.”

I began by extracting the CIDR blocks for each production VPC, then cross‑referencing them with existing security group rules. I discovered 9 security groups allowing 0.0.0.0/0 on port 22. The corrective script I wrote closed those ports and added bastion‑only ingress.

Next, I enabled VPC flow logs for all VPCs, sending them to a central CloudWatch Log Group with a retention policy of 90 days. Finally, I submitted a business case for AWS Shield Advanced that was approved after I demonstrated a recent DDoS attempt on a public API. The combined effort cut the organization’s external attack surface by an estimated 42 % according to the internal risk model.

Which AWS services demand early‑day security instrumentation?

The answer: instrument IAM activity, S3 bucket policies, and Lambda function permissions within the first 45 days. In a hiring‑committee meeting after my interview, the panel emphasized “visibility over everything.” The judgment is not “instrument everything,” but “instrument the highest‑impact services first.”

I began with CloudTrail. I verified that CloudTrail was enabled in all regions and that logs were encrypted with a dedicated KMS key. Then I created a CloudWatch metric filter that raised an alarm on any “CreateUser” or “DeleteUser” event, delivering a Slack notification to the security channel.

For S3, I ran an inventory job that listed all buckets and checked for public ACLs. The scan found 7 buckets with public read access; I applied bucket policies that restricted access to the internal VPC endpoint only. Finally, I audited all Lambda functions for the “AWSLambdaBasicExecutionRole” usage and replaced it with a least‑privilege custom role where possible. By day 45, the metric alerts had triggered three true‑positive incidents, each resolved within 2 hours, providing concrete evidence of early impact.

How to demonstrate impact to my hiring manager by day 60?

The answer: produce a risk‑reduction dashboard that ties remediation actions to business‑critical assets and quantifies avoided exposure. In a 60‑day sync, the hiring manager asked “what’s the ROI of your work?” The judgment is not “show a list of tickets,” but “translate tickets into risk dollars.”

I built a Tableau dashboard that pulled data from the internal risk register, IAM scoring sheet, and CloudWatch alarms. Each remediation ticket was assigned a risk score based on the affected asset’s criticality (high, medium, low) and the privilege weight of the policy fixed.

The dashboard displayed a cumulative risk‑reduction figure—$1.2 M in avoided exposure according to the company’s risk model. I presented this in a 20‑minute meeting with the security director, the engineering VP, and the CFO. The clear, numbers‑driven story earned me a formal commendation and a budget increase for a dedicated security tooling fund.

When and how to negotiate compensation after the 90‑day review?

The answer: initiate the conversation during the 90‑day performance review, using documented risk reduction and market data to anchor the request. In a post‑review debrief, the senior manager said “your numbers are impressive, but we have a salary band.” The judgment is not “wait for a raise,” but “anchor the raise with evidence before the band discussion closes.”

I prepared a one‑page brief that listed three quantifiable achievements—28 % reduction in privileged IAM policies, 42 % decrease in external attack surface, and $1.2 M risk avoided. I paired this with market data from Levels.fyi showing a median base of $152,000 for comparable roles, plus a 0.07 % equity grant typical for senior engineers.

I requested a $12,000 base increase and a 0.03 % equity bump. The manager approved the base raise and promised to revisit equity in the next compensation cycle. The key is to lock in the base adjustment now and treat equity as a future lever.

Preparation Checklist

• Review the IAM policy inventory and flag any role with >3 privilege weight before day 5.
• Enable CloudTrail in all regions and configure a KMS key for log encryption by day 7.
• Harden security groups with a “deny‑by‑default” rule set by day 14.
• Deploy VPC flow logs to a centralized CloudWatch Log Group with a 90‑day retention policy by day 21.
• Run a bucket‑public‑access scan and remediate any ACLs by day 28.
• Instrument Lambda permissions and replace generic execution roles with scoped custom roles by day 35.
• Work through a structured preparation system (the PM Interview Playbook covers risk‑scoring frameworks with real debrief examples, so you can rehearse the same judgment language you’ll need on day 60).

Mistakes to Avoid

• BAD: “Patch every service indiscriminately.” GOOD: “Prioritize privileged IAM and public‑exposed resources, then expand.” The error is treating all tickets as equal; the correct approach is to rank by business impact.
• BAD: “Report a checklist of completed tasks.” GOOD: “Translate each task into a risk metric and present a consolidated reduction figure.” The former shows activity; the latter shows value.
• BAD: “Ask for a raise without data.” GOOD: “Anchor the request with quantified risk avoidance and market salary benchmarks.” The former appears entitlement‑driven; the latter is evidence‑driven.

FAQ

What is the most compelling metric to show early impact?

The judgment: present a risk‑reduction dollar estimate derived from the internal risk model, not a simple ticket count. This metric directly ties technical work to business financials and satisfies executives.

Should I focus on cloud‑native tools or third‑party solutions in the first 90 days?

The judgment: use AWS‑native services first—CloudTrail, GuardDuty, Config—because they integrate with existing governance processes, not because third‑party tools are inherently better.

How many interview rounds are typical before landing a security engineer role at a large cloud company?

The judgment: expect four interview rounds—phone screen, technical deep dive, system‑design, and culture fit—rather than assuming a single interview will suffice. Each round filters a different competency, and preparation should reflect that structure.

The 0→1 PM Interview Playbook (2026 Edition) — view on Amazon →