VigilWatch

Small teams still need to know when a service becomes unreachable, but running a dedicated monitoring server introduces infrastructure, maintenance and cost that can be disproportionate to the workload. VigilWatch explores a different model: use managed AWS services to schedule checks, record incidents and notify someone when an endpoint stops behaving as expected.

The monitoring loop is event-driven from end to end. EventBridge provides the schedule, Lambda performs the health check, DynamoDB persists the resulting state, and SNS handles notifications. Separately, API Gateway and Lambda expose the data to the dashboard, while S3 and CloudFront serve the frontend. CloudWatch provides the operational feedback loop across the system, and Terraform defines the infrastructure as code.

Serverless over a monitoring server

The workload is periodic rather than continuously compute-bound. Using EventBridge and Lambda avoids keeping a process alive solely to wait for the next check and shifts scaling and host maintenance to managed services.

DynamoDB for monitoring state

Monitoring produces predictable key-value access patterns around endpoints, checks and incidents. DynamoDB provides a managed persistence layer without introducing a database server to operate.

Terraform as the deployment boundary

The project treats infrastructure as part of the application rather than as manual console configuration. Terraform makes the architecture reviewable, repeatable and easier to tear down or recreate.

Security before convenience

Service-to-service access is intentionally constrained through least-privilege IAM rather than giving Lambda or other components broad permissions simply to make the first deployment work.

No VPC for a workload that doesn't need one

Lambda talks to managed AWS services and to external HTTP endpoints, not to anything inside a private network, so adding a VPC would have meant subnets, route tables, NAT gateways and security groups justified by nothing. The system relies on AWS-managed networking instead, and a VPC stays out of the design until a real requirement actually needs one.

Infrastructure as Code

The repository separates Terraform infrastructure, Lambda functions, the static frontend, tests and documentation. The deployment path therefore covers both application code and the AWS resources required to run it.

Operational feedback loop

CloudWatch is treated as part of the system rather than an afterthought: logs and metrics provide the evidence needed to understand what the scheduled checks and downstream services are doing.

Getting from terraform apply to a working system surfaced failures at almost every seam rather than one dramatic bug: duplicate provider blocks across Terraform files, variables referenced before they were declared, Lambda deployment packages Terraform expected that the build hadn't produced yet, an API Gateway route with no Lambda integration wired to it, and a CloudFront distribution returning 403s until the S3 origin was locked down behind Origin Access Control instead of public bucket access. None of these were individually surprising — the lesson was that a serverless stack has as many integration seams as it has services, and each one (Terraform → package → API Gateway → Lambda → CloudFront → S3) needs to be verified on its own rather than assumed to work because the previous layer did.

VigilWatch demonstrates an end-to-end serverless monitoring platform with scheduled checks, persistent incident state, alert delivery, a browser-based dashboard, Terraform-managed infrastructure, testing and CloudWatch observability. The architecture is intentionally production-inspired while leaving further hardening such as dead-letter queues, authentication, tracing and multi-region monitoring as future work.

Cloud architecture is about failure modes

Knowing what an AWS service does is not enough. The important engineering work is understanding how services interact, what happens when one stage fails, and how the system makes that failure visible.

Infrastructure belongs in version control

Terraform turns cloud architecture into a reviewable artefact. That makes infrastructure changes easier to reason about alongside application changes and reduces dependence on undocumented console state.

Serverless is a trade-off

Removing servers reduces operational overhead, but it does not remove complexity. Cold starts, dependency packaging, concurrency behaviour, IAM boundaries and distributed debugging still have to be designed for explicitly once the checker Lambda is actually running on a schedule against real endpoints.

Observability has its own cost curve

CloudWatch usage and metric cardinality turned into a cost lesson of their own — an overly granular metrics strategy can get expensive at scale. Observability needs the same cost-consciousness applied to the rest of the architecture, not a blank check because it's 'just logs'.