DEV Community: Josh Blair

Building a Production Company Website on AWS — Project Overview

Josh Blair — Wed, 20 May 2026 22:07:38 +0000

What We Built

This series documents the end-to-end process of designing, building, and deploying a production company website for a software and cloud consulting business. The result is a modern, fully serverless stack with automated CI/CD deployments — built intentionally to demonstrate and practice the AWS services I use professionally.

Tech stack at a glance:

Layer	Technology
Frontend	React 18 + Vite + TypeScript + Tailwind CSS v4
Hosting	Amazon S3 + CloudFront (CDN)
DNS & TLS	Route 53 + ACM (SSL/TLS certificate)
CI/CD	GitHub + AWS CodePipeline + CodeBuild
Contact API	API Gateway (HTTP) + AWS Lambda (Python)
Data storage	Amazon DynamoDB
Email delivery	Amazon SES
IaC	AWS CloudFormation + AWS SAM

Architecture Overview

CI/CD Pipeline

Every push to the main branch on GitHub automatically triggers a full build and deploy:

Articles in This Series

#	Article	What it covers
1	Project Overview (this article)	Full architecture, stack decisions, what we're building
2	React + Vite + Tailwind Setup	Scaffolding the SPA, routing, design system, component structure
3	Static Site Hosting on AWS	S3, CloudFront with OAC, ACM, Route 53 DNS, CloudFormation
4	CI/CD with CodePipeline & CodeBuild	GitHub connection, pipeline stages, buildspec.yml, IAM roles
5	Serverless Contact Form	Lambda, API Gateway, DynamoDB, SES, CORS, SAM deployment

Key Design Decisions

Why React + Vite (not Next.js)?

Next.js is a great framework, but for a static marketing site, it's overhead. Vite produces a clean static build (dist/) that S3 + CloudFront serves perfectly. The site has no server-side rendering requirements. Vite also gives faster local dev iteration.

Why S3 + CloudFront (not Amplify or Vercel)?

This project is intentionally built on "raw" AWS primitives — CodePipeline, CloudFormation, S3, CloudFront — rather than abstracted platforms. The goal is to learn and demonstrate AWS services used in real enterprise projects.

Why CloudFormation (not CDK or Terraform)?

CloudFormation is the AWS-native tool that every AWS practitioner encounters. Understanding it directly — before abstracting to CDK — builds a stronger mental model of what's actually being deployed.

Why separate ACM cert in us-east-1?

CloudFront is a global service and requires ACM certificates to be provisioned specifically in us-east-1, regardless of where your other resources live. This is an AWS constraint, not a design choice.

Why CloudFront OAC (not OAI)?

Origin Access Control (OAC) is the modern replacement for Origin Access Identity (OAI). It supports all S3 operations, works with SSE-KMS encrypted buckets, and uses AWS SigV4 signing.

Repository Structure

bonefishsoftware.com/
├── src/                    # React source
│   ├── components/         # Navbar, Footer, SectionHeader
│   ├── pages/              # Home, Services, Technologies, Portfolio, Team, Contact
│   └── data/               # services.ts, technologies.ts, team.ts
├── public/                 # Static assets (logo, sitemap, robots.txt)
├── lambda/
│   └── contact/            # Python Lambda — contact form handler
├── infra/
│   ├── acm/                # certificate.yml (deploy to us-east-1)
│   └── stacks/
│       ├── website.yml     # S3 + CloudFront (deploy to us-west-2)
│       ├── pipeline.yml    # CodePipeline + CodeBuild (deploy to us-west-2)
│       └── contact-api.yml # SAM — API Gateway + Lambda + DynamoDB (deploy to us-west-2)
├── docs/                   # This documentation
├── buildspec.yml           # CodeBuild build spec
└── index.html              # Vite entry point with SEO meta tags

Serverless Contact Form — Lambda, API Gateway, DynamoDB, and SES

Josh Blair — Wed, 20 May 2026 22:07:35 +0000

Overview

The contact form on bonefishsoftware.com is fully serverless — no EC2, no always-on server. A visitor submits the form, the request hits an API Gateway HTTP API, a Python Lambda function validates and stores the submission in DynamoDB, then sends an email notification via SES. Cost at low volume: effectively zero.

Flow

Infrastructure — AWS SAM

The contact API is deployed using AWS SAM (Serverless Application Model), a CloudFormation extension that simplifies Lambda + API Gateway resource definitions.

Why SAM over plain CloudFormation?

SAM's AWS::Serverless::Function with Events automatically creates the API Gateway routes, integrations, Lambda permissions, and stage. Doing this in plain CloudFormation requires 6–8 separate resource definitions. SAM condenses it to one function resource with an Events section.

Key lesson: `AWS::Serverless::HttpApi` vs `AWS::ApiGatewayV2::Api`

The most important thing to get right: when using SAM's HttpApi event type, the ApiId must reference an AWS::Serverless::HttpApi resource — not a native AWS::ApiGatewayV2::Api.

Using the wrong resource type results in the SAM transform silently skipping route and integration creation, leaving you with a deployed API that returns 404 on every request.

# ✅ Correct — SAM manages routes/integrations automatically
ContactApi:
  Type: AWS::Serverless::HttpApi
  Properties:
    CorsConfiguration:
      AllowOrigins: [https://bonefishsoftware.com]
      AllowMethods: [POST, OPTIONS]
      AllowHeaders: [Content-Type]

ContactFunction:
  Type: AWS::Serverless::Function
  Events:
    PostContact:
      Type: HttpApi
      Properties:
        ApiId: !Ref ContactApi   # ← references Serverless::HttpApi
        Path: /contact
        Method: POST

# ❌ Wrong — routes NOT created by SAM
ContactApi:
  Type: AWS::ApiGatewayV2::Api  # ← native resource, SAM ignores events

Lambda Function (Python)

# lambda/contact/handler.py

import json, os, uuid
from datetime import datetime, timezone
import boto3
from botocore.exceptions import ClientError

ALLOWED_ORIGIN = os.environ.get("ALLOWED_ORIGIN", "https://bonefishsoftware.com")
TABLE_NAME = os.environ["TABLE_NAME"]
FROM_ADDRESS = os.environ["FROM_ADDRESS"]
TO_ADDRESS = os.environ["TO_ADDRESS"]

dynamodb = boto3.resource("dynamodb")
ses = boto3.client("ses")

def handler(event, context):
    # Handle CORS preflight
    if event.get("requestContext", {}).get("http", {}).get("method") == "OPTIONS":
        return _response(200, {})

    # Parse and validate
    try:
        body = json.loads(event.get("body") or "{}")
    except (json.JSONDecodeError, TypeError):
        return _response(400, {"error": "Invalid request body."})

    name    = (body.get("name") or "").strip()
    email   = (body.get("email") or "").strip()
    message = (body.get("message") or "").strip()
    company = (body.get("company") or "").strip()

    if not name or not email or not message:
        return _response(400, {"error": "Name, email, and message are required."})

    if "@" not in email or "." not in email.split("@")[-1]:
        return _response(400, {"error": "Please provide a valid email address."})

    submission_id = str(uuid.uuid4())
    timestamp = datetime.now(timezone.utc).isoformat()

    try:
        _save_to_dynamo(submission_id, timestamp, name, email, company, message)
        _send_email(submission_id, timestamp, name, email, company, message)
    except ClientError as e:
        print(f"AWS error: {e}")
        return _response(500, {"error": "Failed to process your message. Please try again."})

    return _response(200, {"message": "Message received! We'll be in touch soon."})

Why no external dependencies?

Python's boto3 SDK is built into the Lambda runtime — no requirements.txt needed. The deployment package is just a single handler.py file, keeping Lambda cold-start time minimal.

Validation approach

Validation is intentionally lightweight:

Required field presence check
Naive email format check (contains @ and a . after it)

We're not the primary spam defense here — the contact form has no public financial incentive to spam, and rate limiting can be added at the API Gateway level later if needed.

DynamoDB Table

SubmissionsTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: bonefish-contact-submissions
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - AttributeName: submissionId
        AttributeType: S
      - AttributeName: timestamp
        AttributeType: S
    KeySchema:
      - AttributeName: submissionId
        KeyType: HASH
      - AttributeName: timestamp
        KeyType: RANGE

PAY_PER_REQUEST billing — no provisioned capacity to manage. At the volume of a contact form (single-digit submissions per day at most), this costs essentially nothing.

Composite key (submissionId + timestamp) — the UUID ensures uniqueness; the timestamp makes it easy to sort and query submissions chronologically in future tooling.

SES Email Delivery

Domain verification (DKIM)

Emails sent from noreply@bonefishsoftware.com require the domain to be verified in SES. This involves adding three DKIM CNAME records to Route 53:

aws sesv2 create-email-identity \
  --email-identity bonefishsoftware.com \
  --region us-west-2
# → returns 3 DKIM tokens

# Add CNAME records: <token>._domainkey.bonefishsoftware.com → <token>.dkim.amazonses.com

DKIM signing tells receiving mail servers that the email genuinely came from our domain, improving deliverability and preventing spoofing.

Sandbox mode

By default, SES operates in sandbox mode — you can only send to verified email addresses. This is sufficient for the contact form (we only send TO josh.blair@gmail.com, which is verified). The submitter's email address appears only in the Reply-To header and the email body — never as a direct recipient.

SES production access (removing sandbox restrictions) was requested via:

aws sesv2 put-account-details \
  --mail-type TRANSACTIONAL \
  --website-url https://bonefishsoftware.com \
  --use-case-description "..." \
  --production-access-enabled

Reply-To header

ses.send_email(
    Source=FROM_ADDRESS,                  # noreply@bonefishsoftware.com
    Destination={"ToAddresses": [TO_ADDRESS]},  # josh.blair@gmail.com
    Message={...},
    ReplyToAddresses=[email],             # submitter's email
)

Setting ReplyToAddresses to the submitter's email means hitting "Reply" in gmail automatically addresses the response to the client — no copy-pasting required.

CORS Configuration

CORS is configured at the API Gateway level (not in the Lambda response), via the AWS::Serverless::HttpApi resource:

ContactApi:
  Type: AWS::Serverless::HttpApi
  Properties:
    CorsConfiguration:
      AllowOrigins:
        - https://bonefishsoftware.com
        - http://localhost:5173    # local dev
      AllowHeaders:
        - Content-Type
      AllowMethods:
        - POST
        - OPTIONS
      MaxAge: 300

The Lambda still returns Access-Control-Allow-Origin headers in its response (for safety), but API Gateway handles the OPTIONS preflight response automatically.

Lesson learned: An early version used AWS::ApiGatewayV2::Api instead of AWS::Serverless::HttpApi. The CORS configuration was present but the routes were never created — resulting in 404 responses and CORS errors in the browser. Switching to AWS::Serverless::HttpApi resolved both issues simultaneously.

Frontend Integration

The contact form in React fetches the API URL from a Vite environment variable:

// src/pages/Contact.tsx
const apiUrl = import.meta.env.VITE_CONTACT_API_URL;

async function handleSubmit(e: React.FormEvent) {
  e.preventDefault();
  setStatus('submitting');
  try {
    const res = await fetch(apiUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(form),
    });
    if (!res.ok) throw new Error('Request failed');
    setStatus('success');
  } catch {
    setStatus('error');
  }
}

VITE_CONTACT_API_URL is injected at build time by CodeBuild as an environment variable. Vite replaces import.meta.env.VITE_* references with literal string values during the build — there's no runtime environment lookup.

SAM Deployment

sam deploy \
  --template-file infra/stacks/contact-api.yml \
  --stack-name bonefish-contact-api \
  --region us-west-2 \
  --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \
  --s3-bucket bonefish-pipeline-artifacts-709085484102 \
  --s3-prefix sam-contact \
  --no-confirm-changeset

CAPABILITY_AUTO_EXPAND is required when the template uses Transform: AWS::Serverless-2016-10-31. This tells CloudFormation to expand SAM macros before processing the template.

SAM packages the Lambda code (zips lambda/contact/), uploads to the artifacts S3 bucket, and replaces the local CodeUri path with the S3 URL in the transformed template — all automatically.

Cost Analysis

At typical consulting site traffic:

Resource	Usage	Estimated cost
API Gateway HTTP API	100 requests/month	$0.001
Lambda	100 invocations × 128MB × 500ms	< $0.01
DynamoDB	100 writes, PAY_PER_REQUEST	< $0.01
SES	100 emails	$0.01
Total		< $0.05/month

The entire contact form backend costs pennies per month.

CI/CD with AWS CodePipeline and CodeBuild

Josh Blair — Wed, 20 May 2026 22:07:31 +0000

Overview

Every push to the main branch on GitHub automatically builds the React app and deploys it to S3 + CloudFront — zero manual steps. This article covers how that pipeline is wired together using AWS CodePipeline, CodeBuild, and GitHub via CodeStar Connections.

Pipeline Flow

CloudFormation Stack

The pipeline infrastructure is defined in infra/stacks/pipeline.yml.

CodeStar Connection (GitHub App)

GitHubConnection:
  Type: AWS::CodeStarConnections::Connection
  Properties:
    ConnectionName: bonefish-github
    ProviderType: GitHub

Manual step required: After deploying the stack, you must go to AWS Console → CodePipeline → Settings → Connections and click "Update pending connection" to authorize the GitHub App. This cannot be automated — AWS requires explicit human approval to grant access to your GitHub account.

When authorizing, install the AWS Connector for GitHub app on your GitHub account and grant it access to the specific repository. "Connect as a GitHub user" only works for CodeBuild — CodePipeline requires the GitHub App.

Artifact Bucket

Intermediate pipeline artifacts (source zip, build output) are stored in a private S3 bucket:

ArtifactBucket:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: !Sub 'bonefish-pipeline-artifacts-${AWS::AccountId}'
    VersioningConfiguration:
      Status: Enabled
    PublicAccessBlockConfiguration:
      BlockPublicAcls: true
      BlockPublicPolicy: true
      IgnorePublicAcls: true
      RestrictPublicBuckets: true

CodeBuild Project

BuildProject:
  Type: AWS::CodeBuild::Project
  Properties:
    Name: bonefish-build
    ServiceRole: !GetAtt CodeBuildRole.Arn
    Artifacts:
      Type: CODEPIPELINE
    Environment:
      Type: LINUX_CONTAINER
      ComputeType: BUILD_GENERAL1_SMALL
      Image: aws/codebuild/standard:7.0
      EnvironmentVariables:
        - Name: S3_BUCKET
          Value: !Ref S3BucketName
        - Name: DISTRIBUTION_ID
          Value: !Ref DistributionId
    Source:
      Type: CODEPIPELINE
      BuildSpec: buildspec.yml

CodePipeline

Pipeline:
  Type: AWS::CodePipeline::Pipeline
  Properties:
    Name: bonefish-website-pipeline
    RoleArn: !GetAtt PipelineRole.Arn
    PipelineType: V2
    Stages:
      - Name: Source
        Actions:
          - Name: GitHub
            ActionTypeId:
              Category: Source
              Owner: AWS
              Provider: CodeStarSourceConnection
              Version: '1'
            Configuration:
              ConnectionArn: !Ref GitHubConnection
              FullRepositoryId: !Sub '${GitHubOwner}/${GitHubRepo}'
              BranchName: !Ref GitHubBranch
              DetectChanges: true
            OutputArtifacts:
              - Name: SourceArtifact
      - Name: Build
        Actions:
          - Name: BuildAndDeploy
            ActionTypeId:
              Category: Build
              Owner: AWS
              Provider: CodeBuild
              Version: '1'
            Configuration:
              ProjectName: !Ref BuildProject
            InputArtifacts:
              - Name: SourceArtifact

DetectChanges: true means CodePipeline automatically triggers on every push to the configured branch — no webhooks to configure manually.

IAM Roles

Two IAM roles are needed: one for CodePipeline, one for CodeBuild.

CodePipeline Role

PipelineRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal:
            Service: codepipeline.amazonaws.com
          Action: sts:AssumeRole
    Policies:
      - PolicyName: PipelinePolicy
        PolicyDocument:
          Statement:
            - Sid: ArtifactBucket
              Effect: Allow
              Action: [s3:GetObject, s3:PutObject, s3:GetObjectVersion, s3:GetBucketVersioning]
              Resource: [!Sub '${ArtifactBucket.Arn}', !Sub '${ArtifactBucket.Arn}/*']
            - Sid: CodeBuild
              Effect: Allow
              Action: [codebuild:BatchGetBuilds, codebuild:StartBuild]
              Resource: !GetAtt BuildProject.Arn
            - Sid: CodeStarConnection
              Effect: Allow
              Action: [codestar-connections:UseConnection]
              Resource: !Ref GitHubConnection

CodeBuild Role

CodeBuildRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal:
            Service: codebuild.amazonaws.com
          Action: sts:AssumeRole
    Policies:
      - PolicyName: CodeBuildPolicy
        PolicyDocument:
          Statement:
            - Sid: Logs
              Effect: Allow
              Action: [logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents]
              Resource: '*'
            - Sid: ArtifactBucket
              Effect: Allow
              Action: [s3:GetObject, s3:PutObject, s3:GetObjectVersion]
              Resource: !Sub '${ArtifactBucket.Arn}/*'
            - Sid: WebsiteSync
              Effect: Allow
              Action: [s3:PutObject, s3:DeleteObject, s3:GetObject, s3:ListBucket]
              Resource:
                - !Sub 'arn:aws:s3:::${S3BucketName}'
                - !Sub 'arn:aws:s3:::${S3BucketName}/*'
            - Sid: CloudFrontInvalidation
              Effect: Allow
              Action: [cloudfront:CreateInvalidation]
              Resource: !Sub 'arn:aws:cloudfront::${AWS::AccountId}:distribution/${DistributionId}'

Principle of least privilege — CodeBuild can only write to the specific S3 bucket and invalidate the specific CloudFront distribution.

buildspec.yml

The build specification lives in the repo root and tells CodeBuild exactly what to do:

version: 0.2

env:
  variables:
    VITE_CONTACT_API_URL: ""  # overridden by CodeBuild project env var

phases:
  install:
    runtime-versions:
      nodejs: 20
    commands:
      - npm ci

  build:
    commands:
      - npm run build

  post_build:
    commands:
      - aws s3 sync dist/ s3://$S3_BUCKET --delete
      - aws cloudfront create-invalidation --distribution-id $DISTRIBUTION_ID --paths "/*"

Key points

npm ci not npm install

npm ci installs exactly what's in package-lock.json and fails if there are any discrepancies. This ensures deterministic builds — the same packages every time, in every environment.

--delete flag on s3 sync

Removes files from S3 that no longer exist in the build output. Without this, deleted pages or renamed assets would stay in S3 forever and get served to users.

CloudFront invalidation

Vite includes content hashes in asset filenames (index-BX7FeaXh.js), so JS/CSS files are automatically cache-busted. However, index.html itself doesn't have a hash — it must be explicitly invalidated so CloudFront fetches the new version immediately.

VITE_CONTACT_API_URL env var

Vite's import.meta.env.VITE_* variables are replaced at build time (not runtime). The API Gateway URL is injected by CodeBuild as an environment variable and baked into the built JS bundle. This means the frontend always has the correct endpoint URL without any runtime configuration.

Troubleshooting the GitHub Connection

The CodeStar Connection requires careful setup. Common issues encountered:

Status: PENDING after stack deploy

Expected. You must visit the AWS Console to authorize it. Cannot be done via CLI.

"No Branch found" error

The GitHub App was authorized but the private repository wasn't explicitly granted access. Fix: GitHub → Settings → Applications → AWS Connector for GitHub → Configure → add the repo.

"Role does not have sufficient permissions" error

After replacing a broken connection with a new one, the CodePipeline IAM role policy still referenced the old connection ARN. Fix: update the codestar-connections:UseConnection resource ARN in the IAM policy to match the new connection ARN.

Deployment Timeline

From git push to live site:

Phase	Duration
CodePipeline detects change	~10 seconds
Source download from GitHub	~15 seconds
`npm ci` (cache warm)	~30 seconds
`npm run build` (tsc + vite)	~15 seconds
`aws s3 sync`	~10 seconds
CloudFront invalidation	~10 seconds
Total	~90 seconds

Full deployment in under two minutes on every push to main.

Static Site Hosting on AWS — S3, CloudFront, ACM, and Route 53

Josh Blair — Wed, 20 May 2026 22:07:27 +0000

Overview

This article covers deploying a static React site to AWS using S3 as the origin, CloudFront as the CDN, ACM for TLS certificates, and Route 53 for DNS. Everything is defined as CloudFormation infrastructure-as-code.

Architecture

CloudFormation Infrastructure

The hosting infrastructure is split across three stacks deployed in sequence:

Stack	File	Region	Purpose
`bonefish-acm`	`infra/acm/certificate.yml`	us-east-1	ACM TLS certificate
`bonefish-website`	`infra/stacks/website.yml`	us-west-2	S3 + CloudFront
`bonefish-pipeline`	`infra/stacks/pipeline.yml`	us-west-2	CI/CD (covered in article 4)

ACM Certificate (us-east-1)

Why us-east-1? CloudFront is a global service that only accepts ACM certificates provisioned in us-east-1. This is an AWS requirement regardless of where your other resources live.

# infra/acm/certificate.yml
Resources:
  Certificate:
    Type: AWS::CertificateManager::Certificate
    Properties:
      DomainName: bonefishsoftware.com
      SubjectAlternativeNames:
        - www.bonefishsoftware.com
      ValidationMethod: DNS

DNS validation: ACM generates two CNAME records that must be added to your DNS zone. Because the domain is managed by Route 53, we added these via CLI:

aws route53 change-resource-record-sets \
  --hosted-zone-id $ZONE_ID \
  --change-batch '{ "Changes": [
    { "Action": "UPSERT", "ResourceRecordSet": {
      "Name": "_bf48ff...bonefishsoftware.com.",
      "Type": "CNAME", "TTL": 300,
      "ResourceRecords": [{"Value": "_ea68....acm-validations.aws."}]
    }}
  ]}'

Once the domain's nameservers resolve correctly, ACM validates automatically (typically 2–5 minutes).

S3 Bucket

The S3 bucket is private — no public access whatsoever. CloudFront accesses it via OAC (Origin Access Control).

WebsiteBucket:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: bonefishsoftware-com-website
    VersioningConfiguration:
      Status: Enabled
    PublicAccessBlockConfiguration:
      BlockPublicAcls: true
      BlockPublicPolicy: true
      IgnorePublicAcls: true
      RestrictPublicBuckets: true

Bucket Policy — allow CloudFront OAC only

WebsiteBucketPolicy:
  Type: AWS::S3::BucketPolicy
  Properties:
    Bucket: !Ref WebsiteBucket
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal:
            Service: cloudfront.amazonaws.com
          Action: s3:GetObject
          Resource: !Sub '${WebsiteBucket.Arn}/*'
          Condition:
            StringEquals:
              AWS:SourceArn: !Sub >-
                arn:aws:cloudfront::${AWS::AccountId}:distribution/${Distribution}

The AWS:SourceArn condition means only our specific CloudFront distribution can read from this bucket — not any other CloudFront distribution in any AWS account.

Origin Access Control (OAC)

OAC is the modern replacement for Origin Access Identity (OAI). Key advantages:

Supports all S3 API operations
Works with SSE-KMS encrypted buckets
Uses AWS SigV4 request signing (more secure)

OriginAccessControl:
  Type: AWS::CloudFront::OriginAccessControl
  Properties:
    OriginAccessControlConfig:
      Name: bonefishsoftware-com-oac
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4

CloudFront Distribution

Distribution:
  Type: AWS::CloudFront::Distribution
  Properties:
    DistributionConfig:
      Enabled: true
      DefaultRootObject: index.html
      Aliases:
        - bonefishsoftware.com
        - www.bonefishsoftware.com
      ViewerCertificate:
        AcmCertificateArn: !Ref CertificateArn
        SslSupportMethod: sni-only
        MinimumProtocolVersion: TLSv1.2_2021
      HttpVersion: http2and3
      Origins:
        - Id: S3Origin
          DomainName: !GetAtt WebsiteBucket.RegionalDomainName
          S3OriginConfig:
            OriginAccessIdentity: ''
          OriginAccessControlId: !GetAtt OriginAccessControl.Id
      DefaultCacheBehavior:
        TargetOriginId: S3Origin
        ViewerProtocolPolicy: redirect-to-https
        CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6  # CachingOptimized
        Compress: true
      CustomErrorResponses:
        - ErrorCode: 403
          ResponseCode: 200
          ResponsePagePath: /index.html
          ErrorCachingMinTTL: 0
        - ErrorCode: 404
          ResponseCode: 200
          ResponsePagePath: /index.html
          ErrorCachingMinTTL: 0
      PriceClass: PriceClass_100

Key configuration points

RegionalDomainName not DomainName

Always use WebsiteBucket.RegionalDomainName (e.g. bucket.s3.us-west-2.amazonaws.com) when configuring an S3 origin with OAC. Using the global DomainName can cause redirect loops.

PriceClass_100

CloudFront price classes control which edge locations serve your content. PriceClass_100 covers North America and Europe — the right choice for most US-based businesses. PriceClass_All includes Asia/Pacific/South America but costs more.

http2and3

Enables HTTP/2 and HTTP/3 (QUIC) — better performance for browsers that support it.

Route 53 DNS Setup

Since the domain is registered in Route 53, nameservers were updated via CLI:

aws route53domains update-domain-nameservers \
  --domain-name bonefishsoftware.com \
  --region us-east-1 \
  --nameservers \
    Name=ns-1325.awsdns-37.org \
    Name=ns-759.awsdns-30.net \
    Name=ns-1601.awsdns-08.co.uk \
    Name=ns-72.awsdns-09.com

Two Alias records point the apex domain and www to CloudFront:

aws route53 change-resource-record-sets \
  --hosted-zone-id $ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "bonefishsoftware.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "d39qxh6q0wxdkd.cloudfront.net",
          "EvaluateTargetHealth": false
        }
      }
    }]
  }'

Z2FDTNDATAQYW2 is the fixed Hosted Zone ID for all CloudFront distributions — not specific to yours. Always use this value for CloudFront A alias records.

Deployment Order

The order matters because each stack depends on outputs from the previous:

1. Create Route 53 hosted zone
   → Get nameservers, update domain registrar

2. Deploy ACM certificate stack (us-east-1)
   → Add DNS validation CNAMEs to Route 53
   → Wait for ISSUED status (~2–5 min once DNS propagates)

3. Deploy website stack (us-west-2)
   → Pass CertificateArn as parameter
   → Outputs: BucketName, DistributionId, DistributionDomain

4. Deploy pipeline stack (us-west-2)
   → Pass BucketName + DistributionId from step 3

Gradual Cutover Strategy

Rather than blocking on the ACM cert, the website.yml template supports deploying without a cert first:

Parameters:
  CertificateArn:
    Type: String
    Default: ''   # ← Leave blank for initial deploy

Conditions:
  HasCustomDomain: !And
    - !Not [!Equals [!Ref CertificateArn, '']]
    - !Not [!Equals [!Ref DomainName, '']]

This lets you deploy the full CloudFront + S3 stack immediately, get the CloudFront URL (*.cloudfront.net), test it, and then update the stack with the cert ARN once it's issued — no downtime, no waiting.

SES DKIM Records

For outbound email from noreply@bonefishsoftware.com, three DKIM CNAME records were added to Route 53:

jbly6mlsiqbi6h7rnnfthdfkiaxzmvjn._domainkey.bonefishsoftware.com
  → jbly6mlsiqbi6h7rnnfthdfkiaxzmvjn.dkim.amazonses.com

xj7cx3tujwzexkmsxmfruyannxq3sevj._domainkey.bonefishsoftware.com
  → xj7cx3tujwzexkmsxmfruyannxq3sevj.dkim.amazonses.com

fyee6qf6o4fzqiolzxl2dyd4rjboqw4l._domainkey.bonefishsoftware.com
  → fyee6qf6o4fzqiolzxl2dyd4rjboqw4l.dkim.amazonses.com

These allow SES to cryptographically sign outbound emails, which improves deliverability and prevents spoofing.

React + Vite + TypeScript + Tailwind CSS v4 — Project Setup

Josh Blair — Wed, 20 May 2026 22:07:24 +0000

Overview

This article covers scaffolding a production-ready React single-page application using Vite, TypeScript, and Tailwind CSS v4. This is the frontend that gets built into static assets and served from S3 + CloudFront.

Tech Choices

Vite over Create React App

CRA is deprecated. Vite is the modern standard — it uses native ES modules for near-instant dev server startup and produces an optimized production build via Rollup.

TypeScript

Type safety catches bugs at compile time instead of runtime. The CloudFormation templates and the site itself are both infra-as-code; TypeScript gives the same discipline on the frontend.

Tailwind CSS v4

Tailwind v4 (released 2024) is a ground-up rewrite. Key changes from v3:

No tailwind.config.js — theme customization moves into CSS via @theme in your stylesheet
No PostCSS config file — use the @tailwindcss/vite Vite plugin instead
CSS-first configuration — design tokens are CSS custom properties

Scaffolding

# Create project with react-ts template
npm create vite@latest . -- --template react-ts

# Install routing and Tailwind
npm install react-router-dom
npm install -D tailwindcss @tailwindcss/vite

vite.config.ts

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  plugins: [react(), tailwindcss()],
})

The @tailwindcss/vite plugin replaces the old PostCSS setup. No postcss.config.js needed.

src/index.css

/* Google Fonts import MUST come before @import "tailwindcss" */
@import url('https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@300;400;500;600;700&display=swap');
@import "tailwindcss";

/* Custom design tokens via @theme (Tailwind v4 CSS-first config) */
@theme {
  --color-bg: #111318;
  --color-surface: #1C2028;
  --color-accent: #00D4FF;
  --color-text: #F0F4F8;
  --color-text-muted: #8B95A3;
  --color-border: #2A3040;
  --font-sans: 'Space Grotesk', system-ui, sans-serif;
}

body {
  background-color: #111318;
  color: #F0F4F8;
  font-family: 'Space Grotesk', system-ui, sans-serif;
  margin: 0;
}

#root {
  min-height: 100dvh;
  display: flex;
  flex-direction: column;
}

Gotcha: In Tailwind v4, @import "tailwindcss" expands to real CSS. Any @import url(...) (like Google Fonts) must appear before it or the browser ignores the font import. This caused a CSS warning in the build until we fixed the order.

Project Structure

src/
├── components/
│   ├── Navbar.tsx        # Sticky nav, mobile hamburger, active link highlighting
│   ├── Footer.tsx        # Logo, nav links, LinkedIn + GitHub icons
│   └── SectionHeader.tsx # Reusable section heading (title + subtitle)
├── pages/
│   ├── Home.tsx          # Hero, featured services, cert strip, CTA banner
│   ├── Services.tsx      # Full 6-card service grid
│   ├── Technologies.tsx  # Grouped tech badges + certifications
│   ├── Portfolio.tsx     # Placeholder project cards
│   ├── Team.tsx          # Bio card with photo, certs, social links
│   └── Contact.tsx       # Form → API Gateway fetch
├── data/
│   ├── services.ts       # Service card data (title, description, icon)
│   ├── technologies.ts   # Tech groups + certifications
│   └── team.ts           # Team member data
├── App.tsx               # BrowserRouter + route config
├── main.tsx              # React DOM root
└── index.css             # Global styles + Tailwind v4 config

Data-driven content

Rather than hardcoding content in page components, all repeated content lives in typed data files:

// src/data/services.ts
export interface Service {
  id: string;
  title: string;
  description: string;
  icon: string;
}

export const services: Service[] = [
  {
    id: 'eda-serverless',
    title: 'Event-Driven Architecture & Serverless',
    description: 'Architect decoupled, resilient systems using SQS, SNS, EventBridge, and Lambda...',
    icon: '⚡',
  },
  // ...
];

This makes it trivial to add, update, or reorder content without touching component markup.

Routing

React Router v7 handles client-side routing:

// src/App.tsx
import { BrowserRouter as Router, Routes, Route, Navigate } from 'react-router-dom';

export default function App() {
  return (
    <Router>
      <Navbar />
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/services" element={<Services />} />
        <Route path="/technologies" element={<Technologies />} />
        <Route path="/portfolio" element={<Portfolio />} />
        <Route path="/team" element={<Team />} />
        <Route path="/contact" element={<Contact />} />
        <Route path="*" element={<Navigate to="/" replace />} />
      </Routes>
      <Footer />
    </Router>
  );
}

SPA Routing on CloudFront

Because React Router handles navigation client-side, all URLs (/services, /team, etc.) point to the same index.html. When a user navigates directly to https://bonefishsoftware.com/team, S3 returns a 403 (key doesn't exist). CloudFront must be configured to map 403 and 404 errors back to index.html:

# In website.yml CloudFormation
CustomErrorResponses:
  - ErrorCode: 403
    ResponseCode: 200
    ResponsePagePath: /index.html
    ErrorCachingMinTTL: 0
  - ErrorCode: 404
    ResponseCode: 200
    ResponsePagePath: /index.html
    ErrorCachingMinTTL: 0

Without this, refreshing any non-root page returns a CloudFront error page.

Design System

Color palette (dark charcoal + electric cyan):

Token	Hex	Usage
`bg`	`#111318`	Page background
`surface`	`#1C2028`	Cards, panels
`surface-2`	`#232936`	Nested surfaces
`accent`	`#00D4FF`	Cyan highlights, links, active states
`text`	`#F0F4F8`	Primary text
`text-muted`	`#8B95A3`	Secondary text, descriptions
`border`	`#2A3040`	Card borders, dividers

Font: Space Grotesk — a modern geometric sans-serif that feels technical but approachable.

Logo Integration

The company logo is an SVG with a transparent background. The white stripe visible in the logo is part of the Colorado flag design — it's not a background fill.

Using the SVG directly in the Navbar (instead of PNG) means:

Zero white-box artifact on the dark background
Infinitely scalable — looks sharp at any size
Small file size

// Navbar.tsx
<NavLink to="/">
  <img src="/logo.svg" alt="Bonefish Software" className="h-10 w-auto" />
</NavLink>

The no-text variant (/logo-icon.svg) is used in the footer where horizontal space is tighter.

Production Build

npm run build
# → tsc -b && vite build
# → dist/ (index.html + hashed JS/CSS bundles)

Build output for this site:

dist/index.html                   0.64 kB │ gzip:  0.39 kB
dist/assets/index-[hash].css     22.21 kB │ gzip:  4.91 kB
dist/assets/index-[hash].js     257.69 kB │ gzip: 81.09 kB

The entire site gzips to under 86 kB — fast on any connection.

DEV Community: Josh Blair

Building a Production Company Website on AWS — Project Overview

What We Built

Architecture Overview

CI/CD Pipeline

Articles in This Series

Key Design Decisions

Why React + Vite (not Next.js)?

Why S3 + CloudFront (not Amplify or Vercel)?

Why CloudFormation (not CDK or Terraform)?

Why separate ACM cert in us-east-1?

Why CloudFront OAC (not OAI)?

Repository Structure

Serverless Contact Form — Lambda, API Gateway, DynamoDB, and SES

Overview

Flow

Infrastructure — AWS SAM

Key lesson: AWS::Serverless::HttpApi vs AWS::ApiGatewayV2::Api

Lambda Function (Python)

Why no external dependencies?

Validation approach

DynamoDB Table

SES Email Delivery

Domain verification (DKIM)

Sandbox mode

Reply-To header

CORS Configuration

Frontend Integration

SAM Deployment

Cost Analysis

CI/CD with AWS CodePipeline and CodeBuild

Overview

Pipeline Flow

CloudFormation Stack

CodeStar Connection (GitHub App)

Artifact Bucket

CodeBuild Project

CodePipeline

IAM Roles

CodePipeline Role

CodeBuild Role

buildspec.yml

Key points

Troubleshooting the GitHub Connection

Deployment Timeline

Static Site Hosting on AWS — S3, CloudFront, ACM, and Route 53

Overview

Architecture

CloudFormation Infrastructure

ACM Certificate (us-east-1)

S3 Bucket

Bucket Policy — allow CloudFront OAC only

Origin Access Control (OAC)

CloudFront Distribution

Key configuration points

Route 53 DNS Setup

Deployment Order

Gradual Cutover Strategy

SES DKIM Records

React + Vite + TypeScript + Tailwind CSS v4 — Project Setup

Overview

Tech Choices

Vite over Create React App

TypeScript

Tailwind CSS v4

Scaffolding

vite.config.ts

src/index.css

Project Structure

Data-driven content

Routing

SPA Routing on CloudFront

Design System

Logo Integration

Production Build

Key lesson: `AWS::Serverless::HttpApi` vs `AWS::ApiGatewayV2::Api`