Contact Page Tech Details

Public contact forms can be a deceptively hard problem. They must accept unauthenticated input from the internet while resisting spam, abuse, and automated traffic — all without introducing user accounts, persistent state, or excessive operational cost.

Design Goals

  • Accept anonymous messages without requiring user authentication
  • Prevent automated abuse and spam at multiple layers
  • Ensure reliable message delivery with clear failure handling
  • Avoid persistent storage and always-on infrastructure
  • Keep operational cost near zero when idle

This project treats a “simple” contact form as a real-world ingestion endpoint. The goal was to design a system that is secure by default, resilient to failure, and inexpensive to operate, while still providing a clean user experience for legitimate visitors.

High-Level Architecture

The contact form is implemented as a small, serverless ingestion pipeline built entirely on managed AWS services. The frontend is a static page, while all validation, delivery, and abuse controls are handled by backend services.

  • Frontend: Static HTML and JavaScript hosted on Amazon S3 and delivered via CloudFront.
  • Public entry point: A single HTTP API exposed through Amazon API Gateway, with CORS explicitly configured for the portfolio domain.
  • Compute: An AWS Lambda function performs server-side validation and message handling.
  • Message delivery: Valid submissions are sent using Amazon Simple Email Service (SES), keeping email credentials and logic out of the browser.
  • Edge protection: AWS WAF is attached at the API boundary to enforce rate limits and block abusive traffic.

This design keeps the frontend thin and untrusted, centralizes validation and delivery logic in the backend, and avoids any always-on infrastructure or persistent storage.

Abuse & Spam Controls

Because the contact form accepts unauthenticated input from the public internet, abuse prevention was treated as a design requirement rather than an afterthought. The system uses multiple independent controls so that no single failure results in unrestricted access.

  • Edge rate limiting: AWS WAF enforces request rate limits before traffic reaches API Gateway or Lambda, reducing exposure to automated abuse.
  • Bot detection: Google reCAPTCHA is required on the client side to block scripted submissions and low-effort spam.
  • Honeypot field: An invisible form field is included to detect automated bots that submit all inputs indiscriminately.
  • Server-side validation: The Lambda function validates required fields, input length, and message structure before attempting delivery.

These controls operate at different layers (edge, client, and backend), providing defense in depth while keeping the submission flow simple for legitimate users.

Reliability & UX Behavior

Because the contact form relies on a remote, serverless backend, the frontend is designed to handle failure explicitly and fail fast rather than leaving users in an indeterminate state.

  • Request timeouts: Client-side submissions enforce a bounded timeout so failed requests do not hang indefinitely.
  • Clear error states: The UI distinguishes between validation errors, blocked submissions, and backend failures, providing actionable feedback to the user.
  • Safe retries: If a submission fails, the user can retry without causing duplicate emails or unintended backend side effects.
  • Thin frontend: The browser performs presentation and orchestration only; all validation and delivery decisions are handled server-side.

This approach prioritizes predictable behavior and clear feedback over optimistic retries, which is appropriate for an unauthenticated, public-facing ingestion endpoint.

Infrastructure as Code & Operations

All backend resources for the contact form are provisioned and managed using Terraform. This ensures the system can be recreated, audited, and modified through controlled infrastructure changes rather than ad-hoc console updates.

  • API & compute: API Gateway routes, Lambda configuration, and IAM roles are defined declaratively, including least-privilege permissions for email delivery.
  • Email delivery: SES identities and sending permissions are managed as infrastructure, keeping credentials out of application code.
  • Security controls: WAF rules and CORS settings are versioned alongside the rest of the stack.
  • Observability: CloudWatch logs provide visibility into request handling and delivery failures without storing message content.

Because the system is fully serverless and event-driven, it incurs near-zero cost when idle and requires no ongoing operational maintenance beyond monitoring and occasional rule adjustments.

Cost Posture

The contact form is designed to operate at minimal and predictable cost. All components are serverless and event-driven, with no persistent storage or always-on compute.

  • Idle cost near zero: No traffic means no Lambda invocations and no API processing.
  • Bounded usage: WAF rate limiting and CAPTCHA prevent uncontrolled request volume.
  • Pay-per-use delivery: Email is sent only for validated submissions, avoiding unnecessary SES usage.

Bottom Line

This project demonstrates how a seemingly simple contact form can be treated as a production-style ingestion endpoint when exposed to the public internet. The design prioritizes security, abuse prevention, reliability, and cost control without relying on user authentication or persistent state.

By combining a thin static frontend with a protected, serverless backend, the system accepts anonymous input safely and predictably. This same pattern applies to other public-facing submission workflows where trust boundaries, failure handling, and operational discipline matter.