serverless-patch

Final Year Project · AWS ap-southeast-5 (Malaysia)

Centralized agentless patch management

One serverless workflow patches Red Hat Enterprise Linux 9 and Windows Server 2022 over SSH and WinRM, checks every update with a rescan, and reports the result. Nothing is installed on the hosts.

Checking the latest patch results… Open the dashboard ↓

  1. EventBridge Schedulerweekly or one-time trigger
  2. Step Functionsparallel branch per host
  3. Lambdacredentials from Secrets Manager
  4. SSH 22 · RHEL 9 WinRM 5986 · Windows 2022
  5. SNS + CloudWatchemail and dashboard

PatchManagement-Dashboard

Mirror of the CloudWatch dashboard · times in MYT (UTC+8) · Host changes the Selected host row · green from 90%, amber 80–90%, red below 80%

Loading…

Loading results…

How a patch cycle runs

Architecture of the agentless patch management systemEventBridge Scheduler starts the Step Functions state machine serverless-patch-cycle, which runs one parallel branch per host. Inside the VPC, the Lambda functions serverless-patch-rhel and serverless-patch-windows take credentials from Secrets Manager through a VPC endpoint and patch rhel-01 and rhel-02 over SSH port 22 and win-01 over WinRM port 5986; no agent is installed on any host. Step Functions publishes the result to Amazon SNS and calls serverless-patch-metrics, which writes host and cycle records to CloudWatch, where the PatchManagement-Dashboard reads them. Its execution status events trigger an EventBridge rule, which runs serverless-patch-site-publisher; the publisher reads CloudWatch and writes the dashboard data to a private S3 bucket. GitHub holds the code, and deploy-site.ps1 uploads the site to S3. CloudFront with an ACM certificate serves the bucket over HTTPS through Origin Access Control to visitors of fyp.ikmaljohari.my, whose DNS is at Cloudflare.1 · PATCHINGVPC · private subnet · ap-southeast-5EventBridge Schedulerweekly or one-time triggerStep Functionsserverless-patch-cycleparallel branch per hostprecheck → patch → rescanλ serverless-patch-rhelSSH clientSecrets ManagerVPC endpoint · SSH key, WinRMλ serverless-patch-windowsWinRM clientrhel-01RHEL 9 · nginx · no agentrhel-02RHEL 9 · MySQL · no agentwin-01Windows Server 2022IIS · no agentSSH 22 · dnf upgrade --securityWinRM 5986 · Windows Update API2 · MONITORING AND WEBSITEAmazon SNSresult email per cycleλ …-metricshost + cycle recordsCloudWatchLogs · Metrics (EMF)PatchManagement-Dashboard(18 widgets)λ …-site-publisherdashboard dataEventBridge rulecycle started / finishedGitHubcode · pull requestsdeploy-site.ps1PowerShell + AWS CLIS3 (private)site files · data/*.jsonCloudFront + ACMHTTPS · cache · OACfyp.ikmaljohari.myCloudflare DNS → visitorspublishexecution status eventsEMFreadsrunswritesuploads the siteOAC
Architecture. Top: one patch cycle, from the schedule to each host, with no agent installed. Bottom: how the results reach CloudWatch, the email and this website; the code lives in GitHub and the data comes from CloudWatch.

  1. Trigger

    EventBridge Scheduler starts the serverless-patch-cycle state machine on the weekly schedule (Sunday 02:00 MYT) or for a one-time run. A run without "mode": "patch" only scans.

  2. Discover and precheck

    Step Functions picks running instances tagged PatchTarget=true and opens a parallel branch per host. Each branch first checks that the host is ready (access, no other update running, free disk space) and that its workload is healthy.

  3. Patch without an agent

    Lambda connects with credentials from Secrets Manager: dnf upgrade --security over SSH on RHEL, the Windows Update API through a one-shot SYSTEM task over WinRM on Windows. The install runs on the host and Lambda polls it.

  4. Verify and report

    After a reboot if needed, each host is rescanned and its workload checked. Only updates the rescan confirms as fixed count as success. The metrics Lambda writes the records to CloudWatch and SNS emails the result.