DEV Community: Nikola Lalović

Recently, I published my first tech blog post about Multi-Brand CDN Architecture for CMS Media Delivery. If you read it, do not hesitate to leave comments and ask questions...

Nikola Lalović — Sat, 31 Jan 2026 20:52:47 +0000

Building a Multi-Brand CDN Architecture: Lessons from Scaling CMS Media Delivery

Nikola Lalović ・ Jan 11

Why Web Accessibility Matters (And Why It's Not Just About Avoiding Lawsuits)

Nikola Lalović — Sat, 31 Jan 2026 20:37:32 +0000

If you're running a real estate website in New York, you've probably heard the term "web accessibility" thrown around. Maybe you've even received one of those scary demand letters. But here's the thing — accessibility isn't just a legal checkbox. It's about making sure everyone can use your website, including the people who need it most.

Let me break this down in a way that actually makes sense.

The Real Reason Accessibility Matters

Before we talk about lawsuits and compliance standards, let's talk about people.

About 1 in 4 adults in the United States lives with some form of disability. That's not a small number. These are people looking for apartments, browsing property listings, trying to download your offering memorandum, or filling out a contact form to schedule a viewing.

When your website isn't accessible, you're essentially putting a "closed" sign in front of a significant portion of your potential clients. Not because you meant to — but because nobody told you the door was locked.

Making your website accessible means:

A person using a screen reader can navigate your property listings
Someone with limited mobility can use your site with just a keyboard
A visitor with low vision can actually read your content
Anyone can download and read your PDFs with assistive technology

This isn't about compliance. This is about treating people with respect and giving everyone equal access to your business.

Okay, But Let's Talk About the Legal Side Too

I won't pretend the legal landscape doesn't exist — especially in New York.

New York has become one of the most active states for web accessibility lawsuits. Law firms actively scan websites for accessibility issues, and real estate companies are frequent targets. Why? Because real estate sites typically have:

PDF documents (offering memorandums, brochures, lease agreements)
Contact forms
Property search features
Image-heavy listings

All of these are common failure points for accessibility.

The standard that courts look to is WCAG 2.1 Level AA — a set of guidelines that define what makes a website accessible. If your site doesn't meet this standard, you're potentially exposed to litigation.

What Actually Works (And What Doesn't)

Here's where I need to be direct with you: accessibility widgets don't solve the problem.

You've probably seen those little accessibility icons on websites — tools like accessiBe, UserWay, and others. They promise one-click compliance. It sounds great, right?

The reality is different. Courts increasingly reject these overlay tools as proof of compliance. Multiple lawsuits have explicitly named websites that already had widgets installed. Why?

Overlay tools don't fix the underlying code problems
Screen reader users often disable or avoid these overlays because they interfere with their assistive technology
They create a false sense of security

Installing a widget and claiming compliance can actually increase your legal risk because it shows you were aware of the issue but chose a shortcut instead of a real solution.

What Actually Reduces Risk

Real accessibility comes from building it into your website properly. Here's what that looks like:

In the code itself:

Proper heading structure (H1, H2, H3 in logical order)
Alt text on every meaningful image
Keyboard navigation that works throughout the site
Forms with proper labels and error messages
Sufficient color contrast
Focus indicators for interactive elements

For your documents:

PDFs that are properly tagged and readable by screen readers
Accessible forms that can be filled out with assistive technology

For your process:

An accessibility statement on your website with a contact method for reporting issues
Regular audits (at least annually, and after any major redesign)
Documentation of your accessibility efforts
A remediation process when issues are reported

This is what defense attorneys actually want to show in court — evidence of ongoing, good-faith effort to maintain accessibility.

The Tools We Use

You don't need expensive consultants to get started. Here are practical tools that help identify issues:

axe DevTools — browser extension that catches many WCAG violations
WAVE — visual feedback about accessibility issues on your page
Lighthouse — built into Chrome, gives you a basic accessibility score
NVDA / VoiceOver — actual screen readers for manual testing

The key is making accessibility part of your development workflow, not an afterthought.

A Better Way to Think About This

Here's my perspective: accessibility and good web design are the same thing.

A website that's easy to navigate with a keyboard is also easier to navigate for everyone. Clear headings help screen reader users, but they also help every visitor scan your content. Proper color contrast isn't just for people with low vision — it helps anyone viewing your site on a phone in bright sunlight.

When you build with accessibility in mind, you build a better website. Period.

What This Means for Your Business

If you're a real estate company in New York, accessibility should be part of your website strategy — not because you're scared of lawsuits, but because:

It opens your business to more potential clients
It demonstrates that you care about all members of your community
It protects you legally (yes, this matters too)
It results in a better website for everyone

The good news is that proper accessibility isn't prohibitively expensive or complicated. It requires attention and expertise, but it's entirely achievable.

Moving Forward

If you're concerned about your website's accessibility, here's a practical starting point:

Run your site through an automated tool like WAVE or axe
Try navigating your site using only your keyboard
Check if your PDFs can be read by a screen reader
Review your forms for proper labeling
Look at your color contrast ratios

These simple checks will tell you a lot about where you stand.

Accessibility isn't a one-time fix — it's an ongoing commitment. But it's a commitment worth making, both for your business and for the people you serve.

Building a Multi-Brand CDN Architecture: Lessons from Scaling CMS Media Delivery

Nikola Lalović — Sun, 11 Jan 2026 13:29:13 +0000

When you're managing multiple brands under one umbrella, serving media assets efficiently while maintaining brand identity and SEO performance becomes a unique challenge. Recently, I architected and implemented a solution that serves CMS media across 7 different brand domains using AWS CloudFront, improving performance, security, and SEO in one go.

Here's the story of how we did it, the challenges we faced, and the lessons learned along the way.

The Challenge

Our organization operates multiple consumer brands across different markets. Each brand has its own website, but all content is managed through a single headless CMS. This setup is great for operational efficiency, but it creates some interesting technical challenges:

The Problems

1. Security Risk

Media files were stored in a publicly accessible Amazon S3 bucket. While convenient, this meant anyone with the bucket URL could access assets directly, bypassing our CDN and potentially causing bandwidth costs.

2. SEO Limitations

All images were served from a generic S3 domain (bucket-name.s3.amazonaws.com). This meant no SEO benefit for individual brand domains from image searches.

3. Performance

Direct S3 access meant no edge caching. Users far from our S3 region experienced slower load times.

4. Multi-Tenancy Complexity

We needed each brand to appear as if it had its own dedicated image infrastructure, while actually sharing the same underlying storage and CDN.

5. Zero-Downtime Requirement

We couldn't afford any downtime during migration. Thousands of existing URLs were already in production across multiple websites.

The Solution Architecture

The solution leverages AWS CloudFront's multi-domain capabilities combined with intelligent folder-based routing. Here's how it works:

Key Architecture Decisions

1. Single CloudFront Distribution with Multiple Aliases

Instead of creating separate distributions for each brand, we use one distribution with multiple domain aliases (CNAMEs). This simplifies management while still allowing brand-specific domains.

2. Origin Access Control (OAC) for Security

We implemented Origin Access Control to ensure S3 bucket access is only possible through CloudFront. Direct S3 URLs return 403 Forbidden. This was a critical security improvement over the previous public bucket setup.

3. Brand-Aware Upload Provider

The CMS uses a custom upload provider that intelligently maps upload folders to CDN domains. When content creators upload to Brand A's folder, the provider automatically generates a URL using images.brand-a.com.

4. Folder-Based Multi-Tenancy

The S3 bucket structure uses simple folder prefixes:

/brand-a/ → Brand A assets
/brand-b/ → Brand B assets
/shared/ → Cross-brand assets

This keeps everything in one bucket while maintaining logical separation.

Implementation Highlights

1. Custom Strapi Upload Provider

We built a custom upload provider for our Strapi CMS that handles the folder-to-domain mapping:

const brandPaths = [
  '', // 0: Shared
  'brand-a', // 1
  'brand-b', // 2
  'brand-c', // 3
  // ... etc
];

const brandCdnUrls = {
  'brand-a': 'https://images.brand-a.com',
  'brand-b': 'https://images.brand-b.com',
  'brand-c': 'https://images.brand-c.com',
  shared: 'https://images.company.com',
};

const getCdnUrl = (folderIndex) => {
  const brand = brandPaths[folderIndex];
  return brandCdnUrls[brand] || brandCdnUrls['shared'];
};

The provider also handles image variants (thumbnails, responsive sizes) by ensuring they follow the same folder structure as their original images.

2. Multi-Domain SSL Certificate

We used AWS Certificate Manager (ACM) to create a single certificate with Subject Alternative Names (SANs) for all brand domains:

aws acm request-certificate \
  --domain-name images.company.com \
  --subject-alternative-names \
    images.brand-a.com \
    images.brand-b.com \
    images.brand-c.com \
  --validation-method DNS

Important Note: CloudFront requires certificates in the us-east-1 region, regardless of where your distribution actually serves content.

3. DNS Configuration

Each brand domain gets a simple CNAME record pointing to the CloudFront distribution:

images.brand-a.com → CNAME → d1234abcd.cloudfront.net
images.brand-b.com → CNAME → d1234abcd.cloudfront.net

4. CORS Configuration

Since the CMS admin panel needs to preview images, we configured CORS through CloudFront Response Headers Policy:

{
  "AccessControlAllowOrigins": [
    "https://cms.company.com",
    "http://localhost:1337"
  ],
  "AccessControlAllowHeaders": ["*"],
  "AccessControlAllowMethods": ["GET", "HEAD", "OPTIONS"],
  "OriginOverride": true
}

The Migration Challenge

The trickiest part wasn't building the infrastructure—it was migrating existing content without breaking anything.

Database URLs Everywhere

Legacy S3 URLs weren't just in simple URL fields. They were buried:

In main URL columns
Inside JSON fields (image variants: thumbnail, small, medium, large)
In rich text content fields
In cached API responses

We had to write careful SQL migrations:

-- Main URLs
UPDATE files
SET url = REPLACE(
  url,
  'https://bucket-name.s3.region.amazonaws.com',
  'https://images.company.com'
)
WHERE url LIKE '%bucket-name.s3.region.amazonaws.com%';

-- JSON columns (PostgreSQL)
UPDATE files
SET formats = REPLACE(
  formats::text,
  'https://bucket-name.s3.region.amazonaws.com',
  'https://images.company.com'
)::jsonb
WHERE formats::text LIKE '%bucket-name.s3.region.amazonaws.com%';

The Cache Gotcha

Here's a mistake we made: We migrated the database URLs on Friday evening. On Monday morning, we noticed some images were still being served with old S3 URLs.

The culprit? Our CMS had an LRU (Least Recently Used) response cache that was serving stale API responses for hours. The cache had to be invalidated manually, which we hadn't planned for.

Lesson: Map all your caching layers before migration. Application caches, CDN caches, browser caches—they all matter.

Phased Rollout Strategy

We couldn't flip a switch and move everything at once. Here's how we did it safely:

Phase 1: Setup Infrastructure

Set up CloudFront distribution with OAC, but kept S3 public. Both old and new URLs worked.

Phase 2: Update CMS

Update the CMS provider to generate new CDN URLs for new uploads. Old content still used S3 URLs.

Phase 3: Test in Staging

Run database migrations in staging. Test extensively.

Phase 4: Production Migration

Run database migrations in production during low-traffic hours.

Phase 5: Cache Invalidation

Invalidate all caches (CloudFront, application, API).

Phase 6: Monitor

Monitor for 2 weeks. Once confident, remove public S3 access.

The key was maintaining dual access (both old S3 URLs and new CDN URLs working) until we were 100% certain everything was migrated.

Performance Improvements

The results were immediately noticeable:

Latency Reduction

Average image load times dropped by ~60% for users in distant geographic locations, thanks to CloudFront's 400+ edge locations.

Origin Offload

Over 95% of image requests now hit the CloudFront cache, dramatically reducing load on our S3 bucket.

Bandwidth Costs

CloudFront data transfer is cheaper than S3, and we're serving more traffic for less money.

SEO Impact

Within weeks, we saw image search traffic increase as brand-specific image domains began building authority in Google Image Search.

Key Lessons Learned

1. Plan Database Migration Early

Don't underestimate where URLs might be hiding. Use database-wide text searches to find all occurrences before you start.

2. Map Your Caching Strategy

Know every layer of caching in your system. Application caches can silently serve stale data even after you've updated the database.

3. Keep Legacy Access During Transition

Maintaining dual access (old S3 URLs + new CDN URLs) gives you a safety net. Don't burn bridges until you're sure you're across.

4. Use Infrastructure as Code

We used AWS CLI scripts for everything, which made replicating the setup across staging and production environments trivial. CloudFormation or Terraform would have been even better.

5. Origin Access Control > Origin Access Identity

If you're starting fresh, use OAC (Origin Access Control) instead of the older OAI (Origin Access Identity). OAC supports more features and is AWS's recommended approach.

6. Monitor Distribution Deployment Times

CloudFront distribution updates can take 15-30 minutes to deploy across all edge locations. Plan your deployment windows accordingly.

7. Test Certificate DNS Validation Early

DNS validation for ACM certificates can sometimes take time, especially if you have multiple domains across different DNS providers. Start this process early.

8. The Architecture Scales Beautifully

Adding a new brand now takes less than an hour: create a folder in S3, add a DNS record, update the provider mapping. The infrastructure doesn't need to change.

Cost Considerations

The total cost breakdown (approximate, for reference):

CloudFront Distribution: $0 monthly fee (pay per use)
Data Transfer: ~$0.085/GB (first 10 TB)
Requests: ~$0.0075 per 10,000 HTTP requests
ACM Certificate: Free (for use with CloudFront)
S3 Storage: Same as before (~$0.023/GB)

Our total costs actually decreased because:

CloudFront caching reduced S3 GET requests (which have a cost)
CloudFront data transfer is cheaper than S3 data transfer
We consolidated multiple buckets into one

When Should You Use This Architecture?

This approach makes sense when:

✅ You're managing multiple brands under one organization
✅ SEO from brand-specific domains matters to your business
✅ You need to improve global content delivery performance
✅ You want to enhance security by restricting S3 access
✅ You're using a headless CMS with an extensible upload provider

It might be overkill if:

❌ You only have one brand
❌ Your audience is geographically concentrated near your S3 region
❌ You don't care about brand-specific SEO for images
❌ You're using a SaaS CMS without customization options

What's Next?

We're considering a few enhancements:

1. Adaptive Image Formats

Automatically serving WebP/AVIF to supporting browsers

2. Smart Image Optimization

On-the-fly resizing using Lambda@Edge

3. Geo-based Routing

Serving region-specific assets based on user location

4. Analytics Integration

Better tracking of which brands' assets are most popular

Conclusion

Building a multi-brand CDN architecture taught me that the technical implementation is often the easy part. The real challenges are:

Managing migration of existing content
Understanding all the layers of caching in your system
Planning for zero-downtime transitions
Making architecture decisions that scale as you grow

The beauty of this solution is its simplicity: one S3 bucket, one CloudFront distribution, simple folder-based routing, and brand-aware URL generation. It scales effortlessly and costs less than more complex alternatives.

If you're facing similar multi-tenant infrastructure challenges, I hope this post gives you a solid starting point. Feel free to adapt the architecture to your specific needs.

Have questions or faced similar challenges? I'd love to hear about your experiences with multi-brand architectures, CDN strategies, or zero-downtime migrations. What worked for you? What would you do differently?

Useful Resources: