Building an AI-Ready Data Foundation

by Rajat Jindal | Feb 12, 2026 | AWS

Why Your Modernisation Strategy Must Account for AI Before You Need It

The architectural decisions you make today will determine whether you can adopt AI in 12 months — or spend 18 months rebuilding to get there.

Introduction

“In the last 18 months, I have watched three enterprise customers complete successful cloud modernisations — and immediately begin re-architecting for AI. Not because the modernisation failed. Because it succeeded in solving the problem they had in 2024, without anticipating the problem they would have in 2026. The CRM we containerised on ECS Fargate runs beautifully. It just cannot feed a Bedrock knowledge base without a 6-month data engineering project that nobody budgeted for. That gap is preventable. This post is about how to prevent it.”

1. The Modernisation Debt You Don’t See Coming

Every enterprise I work with in presales is having two conversations simultaneously: “How do we modernize our legacy platforms?” and “How do we adopt AI?” The problem is, these conversations happen in different rooms — with different stakeholders, different timelines, and different budgets.

The result is predictable: organisations invest 12–18 months modernising their infrastructure — containerizing applications, automating deployments, implementing observability — and then discover that their freshly modernised platform is fundamentally unprepared for AI workloads. The data is in the wrong format, the wrong place, or the wrong structure.

The lesson is clear: modernisation without AI-readiness is incomplete modernisation. Not because every enterprise needs AI today — but because the cost of retrofitting AI-ready data patterns later is 3–5x higher than embedding them from the start.

2. Why This Matters Now: The Data Foundation Is the AI Bottleneck

The market has shifted. AI is no longer an R&D experiment — it’s a board-level strategic priority. But the gap between AI ambition and AI execution is almost always a data problem, not a model problem.

According to Gartner’s February 2025 research, the data foundation gap is so severe that organisations will abandon 60% of AI projects unsupported by AI-ready data through 2026 (Gartner, “Lack of AI-Ready Data Puts AI Projects at Risk,” February 2025). The differentiator is not which model you choose. It’s whether your data is structured, accessible, and governed in a way that AI systems can consume.

Three market forces are making AI-ready data foundations urgent:

• Agentic AI demands structured, accessible enterprise data — Gartner’s Top Strategic Technology Trends for 2025 predicts that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. These agents need semantically indexed, permission-aware, real-time data access. If your data isn’t ready, your agents are useless.
• The cost of retrofitting is exponential — Adding vector search, embedding pipelines, and governance to an existing platform retrofits every layer. Designing for it during modernisation adds ~15% to initial project cost. Retrofitting later adds 3–5x that amount.
• Competitive differentiation is shifting to data quality — Every enterprise has access to the same foundation models. The organisations that win are those whose proprietary data is clean, structured, and accessible to AI systems. Your data is your moat — but only if it’s AI-ready.

3. What “AI-Ready” Actually Means: A Practical Definition

“AI-ready data” is not a marketing term — it’s a set of specific architectural properties that determine whether your data can be consumed by AI systems without significant re-engineering.

4. The Architecture: AI-Ready Data Foundation on AWS

The reference architecture below connects the four layers that together form an AI-ready data foundation. The layers are sequential — data flows from enterprise sources through ingestion and storage into AI consumption — with governance enforced at every stage.

Architecture Diagram

Layer 1: Data Ingestion & Integration

The problem this solves: Enterprise data lives in dozens of sources — CRM databases, ERP systems, document repositories, SaaS applications, operational logs. AI systems need unified access without building point-to-point integrations for each source.

• AWS Glue — Serverless ETL for batch data integration, schema discovery, and data cataloguing
• Amazon Kinesis Data Streams — Real-time data ingestion for operational events
• AWS Glue Data Catalog — Centralised metadata repository that makes data discoverable to AI systems
• Zero-ETL integrations — Direct data flow between operational databases and analytics environments without pipeline management

Strategic decision: Why Glue + Zero-ETL over custom pipelines?

Custom ETL pipelines give you maximum control — but they also give you maximum maintenance burden. AWS Glue handles the undifferentiated work — schema discovery, job scheduling, error handling, auto-scaling — while Zero-ETL integrations eliminate pipelines entirely for supported source-destination pairs.

The real value for AI readiness: Glue Data Catalog creates a metadata layer that AI systems can query to understand what data exists, where it lives, and what it means — without human intervention. This is the foundation for autonomous AI agents that can discover and access enterprise data on their own.

# AWS Glue job — Transform CRM data and generate embeddings for AI consumption
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from awsglue.context import GlueContext
from pyspark.context import SparkContext
import boto3, json
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
# Read from CRM database via Glue Data Catalog
crm_data = glueContext.create_dynamic_frame.from_catalog(
database="crm_database",
table_name="customer_interactions"
)
# Transform: flatten, standardise timestamps, concatenate text fields
transformed = crm_data.apply_mapping([
("customer_id",       "string",    "customer_id",       "string"),
("interaction_date",  "timestamp", "interaction_date",  "timestamp"),
("interaction_type",  "string",    "interaction_type",  "string"),
("subject",           "string",    "subject",           "string"),
("body",              "string",    "body",              "string"),
("resolution_status", "string",    "resolution_status", "string")
])
# Write to S3 in Parquet — AI-ready for analytics AND embedding pipelines
glueContext.write_dynamic_frame.from_options(
frame=transformed,
connection_type="s3",
connection_options={
"path": "s3://crm-data-lake/ai-ready/customer-interactions/",
"partitionKeys": ["interaction_type"]
},
format="parquet"
)

Key design decision: Writing to Parquet format partitioned by interaction type serves dual purposes — analytics tools (Athena, Redshift Spectrum) can query it efficiently, AND embedding generation pipelines can process it in parallel by partition. One write, two AI consumption patterns.

Layer 2: Vector Storage & Semantic Search

Traditional databases answer “find records where customer_id = 12345.” AI systems need to answer “find interactions similar to this customer complaint about delivery delays.” That requires vector representations of your data — embeddings that capture semantic meaning.

My recommendation: Start with Bedrock Knowledge Bases for your first AI use case — it gets you from zero to working RAG in days, not months. Then evaluate S3 Vectors or Aurora pgvector for production workloads where you need more control. The mistake I see most often: teams spending 3 months evaluating vector databases before validating that their AI use case delivers business value.

# Create an S3 Vectors vector index for CRM customer interaction embeddings
aws s3vectors create-vector-bucket \
--vector-bucket-name crm-ai-embeddings
aws s3vectors create-vector-index \
--vector-bucket-name crm-ai-embeddings \
--vector-index-name customer-interactions \
--dimension 1024 \
--distance-metric cosine \
--metadata-configuration '{
"fields": {
"customer_id":        {"dataType": "str"},
"interaction_type":   {"dataType": "str"},
"interaction_date":   {"dataType": "str"},
"resolution_status":  {"dataType": "str"}
}
}'

The metadata configuration is the critical AI-readiness pattern. By attaching structured metadata to each vector, you enable filtered vector search — “find similar complaints, but only for enterprise customers in the last 90 days.” Without metadata, vector search returns semantically similar results with no business context filtering.

Layer 3: AI Consumption — Knowledge Bases & Agents

Raw data and vector embeddings are not useful to end users. The AI consumption layer connects your data foundation to the applications and agents that deliver business value.

• Amazon Bedrock Knowledge Bases — Managed RAG that connects foundation models to your enterprise data
• Amazon Bedrock AgentCore — Platform for building, deploying, and managing AI agents at scale (launched 2025). Provides memory, tool execution, and multi-agent orchestration.
• Amazon Q Business — Enterprise AI assistant that connects to corporate data sources with zero custom development. Unlike Bedrock Knowledge Bases (which requires developer effort to build an application layer), Q Business provides a ready-made conversational interface for non-technical employees — think of it as “enterprise ChatGPT over your internal data” that IT can deploy in days without writing application code.
• Amazon Bedrock Guardrails — Content filtering, topic blocking, and PII redaction for AI outputs
• AWS Lambda — Serverless compute for AI orchestration and custom logic

{
  "name": "crm-customer-knowledge-base",
  "knowledgeBaseConfiguration": {
    "type": "VECTOR",
    "vectorKnowledgeBaseConfiguration": {
      "embeddingModelArn": "arn:aws:bedrock:ap-south-1::foundation-model/amazon.titan-embed-text-v2:0"
    }
  },
  "storageConfiguration": {
    "type": "OPENSEARCH_SERVERLESS",
    "opensearchServerlessConfiguration": {
      "collectionArn": "arn:aws:aoss:ap-south-1:<account-id>:collection/<collection-id>",
      "vectorIndexName": "crm-interactions-index",
      "fieldMapping": {
        "vectorField": "embedding",
        "textField": "content",
        "metadataField": "metadata"
      }
    }
  }
}

Bedrock AgentCore — Orchestrating AI Agents Over Your Data Foundation:

AgentCore provides the runtime for AI agents that can autonomously discover, reason over, and act on enterprise data. Here’s a simplified agent configuration that connects to the CRM knowledge base:

{
  "agentName": "crm-customer-insights-agent",
  "foundationModel": "anthropic.claude-sonnet-4-20250514",
  "instruction": "You are a customer insights agent. Use the CRM knowledge base to answer questions about customer interaction history, resolution patterns, and service trends. Always cite specific interaction records when providing answers.",
  "idleSessionTTLInSeconds": 1800,
  "knowledgeBases": [
    {
      "knowledgeBaseId": "crm-customer-knowledge-base",
      "description": "CRM customer interaction history including support tickets, complaints, and resolutions"
    }
  ],
  "actionGroups": [
    {
      "actionGroupName": "CRMActions",
      "description": "Actions for retrieving and summarising CRM data",
      "actionGroupExecutor": {
        "lambda": "arn:aws:lambda:ap-south-1:<account-id>:function:crm-agent-actions"
      }
    }
  ],
  "memoryConfiguration": {
    "enabledMemoryTypes": ["SESSION_SUMMARY"],
    "storageDays": 30
  }
}

This agent configuration demonstrates the key AgentCore capabilities: it connects to the knowledge base for RAG-grounded answers, has action groups for executing business logic (e.g., creating follow-up tickets), and uses session memory so conversations maintain context across interactions.

A customer support agent can now ask “What similar issues have we resolved for this customer segment?” and get answers grounded in actual CRM interaction history — not hallucinated responses from a general-purpose model. Meanwhile, Amazon Q Business gives non-technical employees the same AI-powered access through a conversational interface — no custom application development required.

Layer 4: Governance & Security

AI systems that access enterprise data must respect the same access controls, data classification, and audit requirements as human users. Without governance, AI becomes a data exfiltration risk.

The most common AI governance failure: An AI system is deployed with access to a broad data lake, and six months later someone realises it can surface PII from HR records in customer-facing responses. Retrofitting governance after deployment means re-engineering data access patterns, re-testing AI outputs, and potentially recalling responses that already reached end users.

Designing governance from the start means:

• Data classification — happens during ingestion (Layer 1), not after AI deployment
• Access controls — inherited by AI services through IAM roles — the same permission model your human users follow
• PII identification — tagged by Amazon Macie before it enters the vector store
• Bedrock Guardrails — filter AI outputs at the application layer as a defence-in-depth measure

{
  "name": "crm-ai-guardrail",
  "sensitiveInformationPolicyConfig": {
    "piiEntitiesConfig": [
      {"type": "EMAIL",   "action": "ANONYMIZE"},
      {"type": "PHONE",   "action": "ANONYMIZE"},
      {"type": "NAME",    "action": "ANONYMIZE"},
      {"type": "ADDRESS", "action": "BLOCK"}
    ]
  },
  "topicPolicyConfig": {
    "topicsConfig": [{
      "name": "internal-financials",
      "definition": "Questions about company revenue, margins, or financial performance",
      "type": "DENY"
    }]
  }
}

This guardrail configuration demonstrates defence-in-depth: even if the underlying data contains PII, the AI output layer anonymises or blocks sensitive information before it reaches the end user.

5. The CRM Modernisation Revisited: What We’d Add for AI-Readiness

In my previous posts, I documented the modernisation of an enterprise CRM platform — containerisation, CI/CD automation, observability, security hardening. That architecture is solid for operational excellence. But if we were designing it today with AI-readiness as a requirement, here’s what would change:

The cost of adding this later vs. now

If we add these capabilities as a retrofit in 12 months, the estimated effort is 8–12 weeks of engineering work — because we’d need to build data export pipelines from production RDS, design a new data lake schema, implement embedding generation, and add governance controls that don’t exist today.

If we’d included them in the original design, the incremental effort would have been 2–3 weeks — because the data flows, access patterns, and governance model would have been designed holistically from the start. That 4–5x cost multiplier is the AI-readiness tax that enterprises pay when they treat modernisation and AI as separate initiatives.

6. A Presales Perspective: How to Position AI-Ready Data in Customer Conversations

In presales engagements, the AI-readiness conversation has become the most effective way to expand modernisation scope — not by overselling AI, but by helping customers avoid a predictable and expensive mistake.

The conversation I have most often goes like this:

Customer: “We want to modernise our CRM/ERP/portal. We’re not thinking about AI yet — that’s a 2027 initiative.”

My response: “That’s fine — you don’t need to build AI capabilities today. But let me show you what happens if we design the data layer without considering AI, and then you want to add it in 18 months.”

Then I walk through the retrofit cost comparison: 2–3 weeks of incremental design now vs. 8–12 weeks of re-engineering later. The math is simple, and it resonates with CFOs who hate paying twice for the same outcome.

Three questions that surface AI-readiness gaps in discovery:

• “If your CEO asked tomorrow for AI-powered insights from this platform’s data, how long would it take to deliver?” — Most customers answer “months” or “I don’t know.” That gap is the opportunity.
• “Where does your unstructured data live, and can any system search it by meaning rather than keywords?” — This surfaces the vector search gap that blocks RAG and agent use cases.
• “Who controls what data your AI systems can access, and how is that audited?” — This surfaces the governance gap that blocks enterprise AI deployment in regulated industries.

7. The Business Case: Why CFOs Should Fund AI-Ready Data Now

For technology leaders building the business case, here are the numbers that resonate in CFO conversations:

Cost avoidance

• Retrofit cost for AI-readiness after modernisation: 8–12 weeks engineering effort (~$150K–$300K for mid-market enterprises)
• Incremental cost to include AI-readiness during modernisation: 2–3 weeks (~$40K–$75K)
• Net savings per platform: $110K–$225K — and most enterprises have 3–5 platforms that will need AI capabilities

Time-to-value acceleration

• Time to first AI use case without AI-ready data: 6–9 months (data re-engineering + AI development)
• Time to first AI use case with AI-ready data: 4–8 weeks (AI development only — data is already prepared)
• Competitive advantage: 4–7 months faster to market with AI-powered features

Risk reduction

• Organisations that deploy AI without governance face an average of 2–3 data incidents in the first year
• Each incident costs $50K–$500K in remediation depending on regulatory exposure
• Governance-first design reduces incident probability by ~80%

8. Cross-Layer Architecture Summary

These layers are not independent — they form a pipeline. Data flows from ingestion through storage into semantic search, consumed by AI applications, governed at every stage. Skip any layer and the pipeline breaks.

9. Lessons for Technology Leaders

• Modernisation without AI-readiness is incomplete modernisation — Design for the requirements your board will mandate in 12–18 months, not just today’s requirements.
• The data foundation is the AI bottleneck, not the model — Every enterprise has access to the same foundation models. Your competitive advantage is the quality, structure, and accessibility of your proprietary data.
• Start with cataloguing, prove with managed services, optimise with purpose-built infrastructure — Glue Data Catalog first, Bedrock Knowledge Bases to prove value, then S3 Vectors or pgvector for production scale.
• Governance enables AI adoption — it doesn’t slow it down — Enterprises that skip governance don’t deploy faster. They deploy and retract. Build governance in from day one.
• The 15% investment today saves the 3–5x retrofit tomorrow — Frame it as insurance to your CFO. It gets funded.
• AI-ready data is a presales differentiator — When you help customers avoid the retrofit tax, you establish trust and expand engagement scope.

Conclusion

“The best time to build an AI-ready data foundation is during your cloud modernisation. The second-best time is now. But there is a third option that most enterprises choose: waiting until the AI use case is approved, the budget is allocated, and the business is asking why it’s taking 18 months to get a Bedrock pilot into production. That third option is the most expensive — and the most common.”

About the Author

Rajat Jindal is VP – Presales at AeonX Digital Technology Limited, where he architects winning cloud strategies for enterprise customers and translates modernization into measurable business value. He is a strong advocate of AWS, committed to sharing thought leadership that helps technology leaders make faster, better-informed decisions.

Applying the AWS Well-Architected Framework to Modernize a Legacy CRM and Employee Portal Platform

by Rajat Jindal | Feb 5, 2026 | AWS

Why Well-Architected Thinking Matters More Than Well-Architected Compliance

Every enterprise I work with in presales has the same initial ask: “Help us move to the cloud.” But migration without architectural intent is just renting someone else’s servers. The real value of cloud modernization comes from making deliberate architectural decisions — and having a framework to evaluate whether those decisions are sound.

The AWS Well-Architected Framework is that evaluation tool. But in my experience, most teams encounter it too late — during a post-deployment review or an AWS Solutions Architect engagement after the architecture is already built. Used early, during discovery and design, it becomes something far more powerful: a shared language between technology teams and business stakeholders for discussing architectural trade-offs in terms both sides understand.

When a CTO hears “we have a reliability gap,” that’s abstract. When they hear “our database is single-AZ with no automated failover, which means a single availability zone failure takes down the entire CRM for 2–4 hours during business hours,” that’s a fundable problem. The Well-Architected Framework gives you the vocabulary to translate architectural debt into business risk — and that translation is what gets modernization projects approved.

This post applies the six pillars to a real CRM and Employee Portal modernization — not as a compliance exercise, but as a demonstration of how Well-Architected thinking shapes better business outcomes from day one.

The Six Pillars Applied

1. Operational Excellence

Goal: Run and monitor systems to deliver business value and continuously improve processes.

The business problem: The legacy environment required 2–3 hour manual deployments with no centralized logging, no automated rollback, and high dependency on human intervention. This wasn’t just an operations inconvenience — it meant the product team could only ship changes during scheduled maintenance windows, limiting the organization’s ability to respond to customer needs.

#### Architectural Decisions

CI/CD Automation:

• GitHub → CodePipeline → CodeBuild → ECR → CodeDeploy → ECS Fargate
• Blue/green deployments with automated rollback
• Infrastructure defined as code

Observability:

• CloudWatch metrics and logs for ECS, ALB, RDS
• Custom CloudWatch alarms with composite alarm patterns
• SNS-based alerting
• CloudTrail API activity logging

{

“AlarmName”: “crm-platform-composite-health”,

“AlarmDescription”: “Composite alarm — triggers only when both ECS task failures AND high ALB error rate occur simultaneously, reducing alert noise”,

“AlarmRule”: “ALARM(crm-ecs-task-failure-alarm) AND ALARM(crm-alb-5xx-rate-alarm)”,

“ActionsEnabled”: true,

“AlarmActions”: [

arn:aws:sns:ap-south-1::crm-oncall-alerts

]

}

# Create the two child alarms first

# 1 — ECS task failure alarm

aws cloudwatch put-metric-alarm \

–alarm-name crm-ecs-task-failure-alarm \

–namespace AWS/ECS \

–metric-name TaskCount \

–dimensions Name=ClusterName,Value=crm-cluster \

–statistic Minimum \

–period 60 \

–threshold 1 \

–comparison-operator LessThanThreshold \

–evaluation-periods 2 \

–alarm-actions arn:aws:sns:ap-south-1::crm-oncall-alerts

# 2 — ALB 5xx error rate alarm

aws cloudwatch put-metric-alarm \

–alarm-name crm-alb-5xx-rate-alarm \

–namespace AWS/ApplicationELB \

–metric-name HTTPCode_Target_5XX_Count \

–dimensions Name=LoadBalancer,Value= \

–statistic Sum \

–period 60 \

–threshold 10 \

–comparison-operator GreaterThanThreshold \

–evaluation-periods 2 \

–alarm-actions arn:aws:sns:ap-south-1::crm-oncall-alerts

# 3 — Composite alarm combining both

aws cloudwatch put-composite-alarm \

–alarm-name crm-platform-composite-health \

–alarm-rule “ALARM(crm-ecs-task-failure-alarm) AND ALARM(crm-alb-5xx-rate-alarm)” \

–alarm-actions arn:aws:sns:ap-south-1::crm-oncall-alerts

The composite alarm is the key operational excellence pattern here. Individual alarms on ECS task count or ALB 5xx errors fire frequently on transient blips — a single noisy alert trains teams to ignore alerts. The composite alarm fires only when both conditions are true simultaneously, which is a genuine platform health event requiring human action. This reduced alert fatigue by ~70% and improved on-call response quality.

#### Business Impact

The 98% reduction in deployment time isn’t an ops metric — it’s a feature velocity metric. The product team can now ship customer-requested changes in hours instead of scheduling them for the next monthly release window. That directly affects customer retention and competitive positioning.

#### Well-Architected Alignment

• Perform operations as code
• Make small, reversible changes
• Refine operations procedures frequently
• Anticipate failure

2. Security

Goal: Protect information, systems, and assets while delivering business value.

The business problem: Hardcoded credentials, no encryption enforcement, no layered network segmentation, and limited audit trails. For a CRM handling customer PII, this wasn’t just technical debt — it was regulatory exposure. Every day these gaps remained open was a day the organization was one audit away from a material finding.

#### Security Controls Implemented

Identity & Access:

• IAM task roles with least privilege
• Role-based CI/CD permissions
• Resource-level IAM policies with explicit deny

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Sid”: “AllowSecretsManagerAccess”,

“Effect”: “Allow”,

“Action”: [“secretsmanager:GetSecretValue”],

Resource”: “arn:aws:secretsmanager:ap-south-1::secret:crm-db-*

},

{

“Sid”: “AllowECRImagePull”,

“Effect”: “Allow”,

“Action”: [

“ecr:GetDownloadUrlForLayer”,

“ecr:BatchGetImage”,

ecr:BatchCheckLayerAvailability

],

Resource”: “arn:aws:ecr:ap-south-1::repository/crm-app

},

{

“Sid”: “AllowCloudWatchLogs”,

“Effect”: “Allow”,

“Action”: [“logs:CreateLogStream”, “logs:PutLogEvents”],

Resource”: “arn:aws:logs:ap-south-1::log-group:/ecs/crm-app:*

},

{

“Sid”: “DenyEverythingElse”,

“Effect”: “Deny”,

“NotAction”: [

“secretsmanager:GetSecretValue”,

“ecr:GetDownloadUrlForLayer”,

“ecr:BatchGetImage”,

“ecr:BatchCheckLayerAvailability”,

“logs:CreateLogStream”,

logs:PutLogEvents

],

Resource”: “*

}

]

}

Secrets Management — Why Secrets Manager Over Parameter Store?

Both AWS Secrets Manager and Systems Manager Parameter Store can store credentials securely, and Parameter Store is free for standard parameters. We chose Secrets Manager for this CRM platform for three specific reasons:

• Automatic secret rotation on a defined schedule without any application code change
• Native integration with RDS to rotate database passwords automatically
• A dedicated audit trail in CloudTrail that logs every secret access event

For a CRM handling customer PII, the rotation capability alone justified the cost — a credential that auto-rotates every 30 days has a fundamentally smaller blast radius than one that relies on manual rotation discipline.

Network Segmentation:

• Public subnets (ALB only)
• Private subnets (ECS + RDS)
• Security Groups for micro-segmentation
• Network ACLs as secondary boundary

Encryption:

• KMS encryption for RDS
• Encrypted S3 storage
• TLS via CloudFront + ALB

Threat Detection & Audit:

• CloudTrail for API logging
• GuardDuty for threat monitoring
• VPC Flow Logs for network visibility

#### Business Impact

Elimination of hardcoded secrets and full audit logging moved the platform from “audit risk” to “audit ready.” For enterprises in regulated industries, this is the difference between a 3-month compliance remediation project and a clean audit. The cost avoidance alone justified the security investment.

#### Well-Architected Alignment

• Implement strong identity foundation
• Enable traceability
• Protect data in transit and at rest
• Apply security at all layers

3. Reliability

Goal: Ensure workload performs correctly and consistently when expected.

The business problem: Single-point-of-failure servers, no fault tolerance, and long downtime during deployment. For a CRM that customer-facing teams depend on during business hours, every outage directly impacts revenue-generating activities.

#### Reliability Enhancements

Compute Layer:

• ECS tasks across multiple Availability Zones
• Fargate-managed infrastructure
• ALB health checks with automatic unhealthy task replacement

Database Layer:

• Amazon RDS multi-AZ deployment
• Automated backups with point-in-time recovery
• Failover completes in 60–120 seconds with no application changes

Deployment Resilience — Why Blue/Green Over Rolling?

Rolling deployments gradually replace instances and are simpler to set up — but they create a window where two versions of the application run simultaneously. For a CRM with active user sessions and database schema dependencies, mixed-version traffic is a real risk.

Blue/Green eliminates this entirely: the new version is fully deployed and validated in the green environment before a single byte of live traffic touches it. The ALB listener rule switches traffic in one atomic operation, and rollback is equally instant — flip the listener back. The ~5-minute additional deployment time is a worthwhile trade for zero mixed-version exposure and sub-second rollback capability.

Edge Resilience:

• CloudFront CDN reduces regional latency impact

#### Business Impact

Zero-downtime deployments eliminated the “deployment freeze” periods that previously blocked releases during business-critical periods (month-end, quarter-close). The business no longer has to choose between stability and progress.

#### Well-Architected Alignment

• Automatically recover from failure
• Test recovery procedures
• Scale horizontally
• Manage change through automation

4. Performance Efficiency

Goal: Use IT and computing resources efficiently.

The business problem: Fixed hardware capacity with no auto-scaling meant the platform was simultaneously over-provisioned (wasting money during off-peak) and under-provisioned (degrading during peak). Neither state served the business well.

#### Optimization Strategies

Serverless Containers:

• ECS with Fargate eliminates overprovisioning
• Scale tasks dynamically based on actual demand

CDN Acceleration:

• CloudFront reduces global latency
• Edge caching for static assets

Auto Scaling:

• ECS task auto-scaling policies
• ALB request-based scaling triggers

Managed Services:

• RDS managed scaling and performance tuning

#### Business Impact

Improved global performance and elastic scalability during CRM peak loads. The platform now handles 3x traffic spikes during month-end processing without degradation — previously these spikes caused timeouts and customer complaints.

#### Well-Architected Alignment

• Democratize advanced technologies
• Go global in minutes
• Use serverless architectures

5. Cost Optimization

Goal: Avoid unnecessary costs.

The business problem: Overprovisioned on-prem hardware, idle compute during lean periods, and manual operations overhead. The CFO couldn’t forecast infrastructure costs because they were disconnected from actual usage.

#### Cost Improvements

Why Fargate Pay-Per-Use Over Reserved EC2?

Reserved EC2 instances offer up to 72% savings over On-Demand pricing — but only when utilisation is consistently high. This CRM platform has predictable business-hours peaks and near-zero overnight traffic.

With EC2 reserved capacity, you pay for overnight compute regardless. Fargate tasks scale to zero during off-peak hours, meaning the overnight cost is literally zero.

We modelled both options: at the platform’s actual utilisation pattern, Fargate came out ~22% cheaper than equivalent Reserved EC2, with the additional benefit of zero capacity management. The trade-off is slightly higher per-vCPU cost at peak — accepted because the off-peak savings more than compensate across a full month.

Reduced Operational Overhead:

• Automation reduced manual labor costs
• No hardware lifecycle management

Managed Services:

• Reduced DBA and infrastructure management effort

#### Business Impact

The 38% cost savings is meaningful, but the real win is cost predictability. The CFO can now forecast cloud spend with confidence because it tracks actual usage, not fixed capacity. Budget conversations shifted from “how much hardware do we need to buy” to “how much did we actually use.”

#### Well-Architected Alignment

• Adopt consumption model
• Measure overall efficiency
• Stop spending on undifferentiated heavy lifting

6. Sustainability

Goal: Minimise the environmental impact of running cloud workloads.

Sustainability is the newest of the six pillars — added in 2021 — and the one most commonly skipped in modernisation blogs. It deserves more than a footnote, because for many enterprises, ESG commitments are now board-level priorities that influence technology decisions.

#### What Changed With This Migration

Server elimination and energy reduction: The legacy CRM ran on dedicated physical servers with fixed power draw — regardless of whether they were serving ten users or ten thousand. Those servers consumed power 24/7, including nights, weekends, and holiday periods when the CRM had near-zero traffic. Fargate tasks scale to zero during off-peak hours, meaning compute energy consumption directly tracks actual workload demand.

AWS infrastructure efficiency advantage: AWS operates at a scale that individual enterprises cannot match. AWS data centres run at Power Usage Effectiveness (PUE) ratings significantly below the industry average of ~1.6 — AWS has published PUE figures approaching 1.2 for its most efficient facilities. Additionally, AWS has committed to powering operations with 100% renewable energy — a commitment that covers the ap-south-1 (Mumbai) region where this workload runs.

Right-sizing and overprovisioning elimination: On-premises infrastructure is typically overprovisioned to handle peak load — meaning average utilisation is far below capacity, and that idle capacity still consumes power. Auto-scaling on ECS Fargate means the platform runs at consistently higher utilisation, with compute matched to demand in real time.

AWS Customer Carbon Footprint Tool: AWS provides the Customer Carbon Footprint Tool in the Cost & Usage dashboard. This tool shows estimated carbon emissions for your AWS usage and compares them against equivalent on-premises emissions. For workloads migrated from physical servers, the reduction is typically substantial — AWS reports that moving on-premises workloads to AWS can reduce carbon emissions by up to 80% depending on region and workload type.

#### Business Impact

For organizations with ESG reporting requirements or sustainability commitments, this migration provides measurable, auditable carbon reduction data. The Customer Carbon Footprint Tool gives the sustainability team the numbers they need for annual reports — without any additional engineering effort.

#### Well-Architected Alignment

• Understand your impact — measure workload emissions using the Carbon Footprint Tool
• Maximise utilisation — Fargate’s serverless model aligns compute consumption with actual demand
• Use managed services — offload infrastructure management to AWS and benefit from their efficiency investments
• Adopt serverless patterns — scale to zero is the most sustainable compute model available

A Presales Perspective: The Well-Architected Framework as a Discovery Tool

In Presales conversations, the AWS Well-Architected Framework is one of the most powerful tools in the discovery toolkit — not because it impresses customers with AWS vocabulary, but because it gives both sides a shared, structured language to talk about architecture debt honestly.

Most enterprise customers I work with know their current architecture has problems. What they struggle with is articulating which problems matter most, why they matter, and in what order to address them. The six pillars change that conversation.

When I walk a customer through a lightweight Well-Architected review — even informally in a whiteboarding session — three things consistently happen:

• They immediately recognise their own pain points in the pillar descriptions
• They start self-identifying gaps they hadn’t formally acknowledged before
• The conversation shifts from “we need to migrate to cloud” to “here are the specific architectural decisions we need to make”

A concrete example: The CRM modernisation described in this blog began exactly that way. A WAF-framed discovery surfaced five distinct risk areas — hardcoded credentials, no automated rollback, single-AZ database, fixed hardware capacity, and zero cost visibility — that the customer had previously described collectively as “our system is old and slow.”

That framing shift, from a vague complaint to five specific, addressable architectural gaps, is what made the business case fundable and the project scoped correctly from day one.

For Presales professionals working with AWS: the Well-Architected Framework is not a post-sale delivery tool. Used early, it is one of the most effective ways to establish technical credibility, structure a customer’s thinking, and build a modernisation roadmap that the customer feels ownership over — because they helped identify the gaps themselves.

When and How to Apply Well-Architected in Your Organization

Based on applying this framework across dozens of enterprise engagements, here’s my recommendation for technology leaders:

• Use it during discovery, not after deployment — WAF is most valuable when it shapes decisions, not when it audits them after the fact. A 2-hour Well-Architected review before design starts saves months of rework later.
• Don’t try to be perfect across all six pillars simultaneously — Identify your top 2–3 risk pillars and address those first. For most enterprises, Security and Reliability are non-negotiable; Cost Optimization and Sustainability can follow in subsequent phases.
• Make it a shared language with business stakeholders — When a CFO hears “Cost Optimization pillar” they understand it immediately. When they hear “right-sizing instances” they tune out. Frame pillar outcomes in business terms that resonate with your audience.
• Run lightweight WAF reviews quarterly, not annually — Architecture decisions drift. A 2-hour quarterly review catches drift before it becomes debt. Make it a standing calendar item, not a one-time exercise.
• Use the pillars to structure your modernization roadmap — Each pillar becomes a workstream with clear ownership, measurable outcomes, and business justification. This makes progress visible to leadership and keeps the program funded.

Cross-Pillar Observations

The pillars are not independent — they reinforce each other. Serverless containers (Performance) also reduce cost (Cost Optimization) and energy waste (Sustainability). Automated deployments (Operational Excellence) also reduce security risk (Security) by eliminating manual access to production. Well-Architected thinking is holistic by design.

Architectural Maturity Assessment

The modernization demonstrates movement from:

❌ Manual, static, monolithic operations → ✅ Automated, elastic, secure, observable cloud-native architecture

It aligns strongly with:

• Infrastructure as Code principles
• DevOps-driven change management
• Zero-trust security posture
• Event-driven automation

Final Reflection

Applying the AWS Well-Architected Framework transforms modernization from a migration project into a structured architecture evolution. It gives technology leaders a vocabulary for discussing trade-offs, a framework for prioritizing investments, and a measurement system for tracking progress.

This CRM & Employee Portal modernization illustrates that:

• Containerization improves agility — but only when paired with automated deployment
• Security must be embedded, not layered later — and it pays for itself in audit avoidance
• Cost optimization is not about spending less — it’s about spending in proportion to value delivered
• Sustainability is no longer optional — it’s a board-level reporting requirement

For technology leaders and presales professionals:

Well-Architected is not a checklist — it is a design discipline. And used early, it is the most effective tool for turning vague modernization aspirations into funded, scoped, measurable programs.

Lessons for Technology Leaders

• Use Well-Architected as a discovery tool, not an audit tool — The framework’s greatest value is in shaping decisions before they’re made, not evaluating them after the fact.
• Translate architectural gaps into business risk — “Single-AZ database” means nothing to a CFO. “One availability zone failure takes down the CRM for 4 hours during business hours” gets budget approved.
• Sustainability is a competitive differentiator — Organizations with measurable cloud sustainability data win RFPs that include ESG criteria. The Customer Carbon Footprint Tool gives you those numbers for free.
• The six pillars are a communication framework, not just a technical framework — Use them to structure conversations with non-technical stakeholders. Each pillar maps to a business concern they already care about.
• Start with your highest-risk pillar, not your most interesting one — Security and Reliability gaps have immediate business consequences. Cost Optimization and Performance can follow once the foundation is solid.

About the Author

Rajat Jindal is VP – Presales at AeonX Digital Technology Limited, where he architects winning cloud strategies for enterprise customers and translates modernization into measurable business value. He is a strong advocate of AWS, committed to sharing thought leadership that helps technology leaders make faster, better-informed decisions.

Architecting a Secure Multi-Application Platform with CI/CD and Cross-Region Disaster Recovery on AWS

by Rajat Jindal | Jan 29, 2026 | AWS

Why Manufacturing Enterprises Can No Longer Ignore Platform Resilience

In precision manufacturing, a single hour of unplanned system downtime doesn’t just cost IT budget — it stops production lines, breaches supplier SLAs, and triggers contractual penalties that can exceed the entire annual cloud spend.

Yet in our presales engagements with manufacturing enterprises across India and Southeast Asia, we consistently find the same pattern: business-critical applications running on infrastructure that has no automated failover, no standardized deployment process, and no tested disaster recovery plan. The gap between business criticality and infrastructure maturity is where the real risk lives.

This is not a technology problem — it’s a business continuity problem that technology leaders are accountable for. When a Tier-1 customer’s supply chain depends on your Supplier Portal being available, “we’ve never had a major outage” is not a risk mitigation strategy — it’s a bet. And the longer you go without an incident, the more catastrophic the eventual one becomes, because the organization has no muscle memory for recovery.

This post documents how we closed that gap for a high-precision manufacturing enterprise running three business-critical applications — and the architectural decisions that made the business case fundable.

How We Built the Business Case

Technical teams often struggle to get modernization funded because they present the problem in technical terms: “we need CI/CD” or “we should move to the cloud.” Executives don’t fund technology — they fund risk reduction, cost avoidance, and competitive advantage.

For this engagement, we framed the business case around three numbers:

• Cost of a single production outage — calculated from SLA penalty clauses in the customer’s Tier-1 supplier contracts. One breach = 6 months of cloud infrastructure cost.
• Developer time lost to manual deployments — 3 senior engineers spending ~20% of their time on deployment coordination. That’s 0.6 FTE of engineering capacity redirected from product development to operations.
• Audit remediation cost — the customer’s last ISO audit flagged 4 findings related to access control and change management. Remediation was quoted at $200K+ by their compliance consultants. The modernized architecture resolves all four findings as a byproduct of good design.

The total business case was 3.2x the project investment in year-one risk avoidance alone — before counting the operational efficiency gains. That’s the framing that gets a CFO to sign.

The Technical Challenges

The enterprise operated three core applications:

• Supplier Portal – A customer-facing application used by vendors for onboarding, order tracking, and supply chain coordination. This system experiences peak traffic during procurement cycles and requires high availability.
• Tool Pulse – An internal analytics and monitoring platform that provides real-time insights into manufacturing operations, equipment utilization, and production efficiency.
• Gauge Caliber – A quality assurance and calibration management system responsible for maintaining measurement accuracy, compliance records, and inspection workflows.

For confidentiality reasons, specific client identifiers and sensitive implementation details have been generalized. The application names used are representative placeholders, while the architecture, deployment patterns, and operational practices reflect the actual solution implemented.

The limitations of the existing environment included:

1. Manual Deployment Model

• No CI/CD — human intervention required for every release
• High rollback risk with long release cycles
• Deployment failures during business hours directly impacted production operations

2. Limited Scalability

• Static infrastructure with no auto-scaling
• Performance degradation during procurement peak cycles
• Over-provisioned hardware sitting idle 70% of the time

3. Security & Compliance Gaps

• No fine-grained IAM controls
• Limited audit visibility — ISO auditors flagged 4 findings
• No structured encryption controls for data at rest

4. Disaster Recovery Risks

• No automated failover — recovery was manual and untested
• High RTO and RPO exposure with no documented runbook
• Single-region deployment with no cross-region capability

5. Operational Overhead

• Physical server management consuming senior engineering time
• Maintenance complexity growing with each application addition
• Infrastructure cost increasing without proportional business value

The objective was not just migration — it was to design a resilient, scalable, DevOps-driven, multi-application platform that reduced business risk while improving delivery velocity.

Solution Architecture Overview

Solution Architecture Overview – Multi-Application Platform with CI/CD and Cross-Region Disaster Recovery on AWS

All three applications were deployed using a standardized pattern:

Strategic Decision: Standardized CI/CD Across All Applications

One of the most impactful design decisions was implementing a centralized CI/CD pipeline pattern across all three applications. This was a deliberate strategic choice, not just a technical convenience.

Why standardization matters more than optimization:

When each application has its own deployment process, you get three different failure modes, three different runbooks, and three different sets of tribal knowledge. Standardization means: – Any engineer can deploy any application — no single points of knowledge failure – One improvement benefits all three applications simultaneously – Incident response follows the same playbook regardless of which application is affected – New applications onboard in days, not weeks

Deployment Flow

• Code committed to GitHub
• CodePipeline triggers automatically
• CodeBuild: compiles application, executes unit tests
• CodeDeploy: deploys to staging, promotes to production EC2 Auto Scaling Group

# appspec.yml — CodeDeploy EC2 Deployment

version: 0.0

os: linux

files:

• source: /

destination: /var/www/app

hooks:

BeforeInstall:

• location: scripts/stop_server.sh

timeout: 60

runas: root

AfterInstall:

• location: scripts/install_dependencies.sh

timeout: 120

runas: root

ApplicationStart:

• location: scripts/start_server.sh

timeout: 60

runas: root

ValidateService:

• location: scripts/validate_service.sh

timeout: 30

runas: root

The ValidateService hook is critical — it runs a health check after deployment. If it fails, CodeDeploy automatically rolls back. This is what gives you safe, repeatable deployments across all three applications without manual intervention.

Business outcome: Release velocity improved by ~60%. More importantly, the risk of each release dropped dramatically — failed deployments auto-rollback instead of requiring 2 AM emergency calls.

Strategic Decision: Why EC2 Over Fargate?

This is a decision that technology leaders face constantly: the ideal architecture vs. the achievable architecture.

Fargate would have been architecturally cleaner — serverless containers with zero infrastructure management. But it would have required 3–4 months of application refactoring before any business value was delivered. These applications had: – OS-level dependencies requiring specific Linux configurations – Tight integration with legacy libraries that assumed filesystem access – A team more experienced with EC2 operations than container orchestration

EC2 with Auto Scaling delivered 80% of the benefit in 40% of the time — and positions the platform for a future Fargate migration once the applications are decoupled from OS-level dependencies.

The lesson for leaders: Don’t let architectural perfection delay business value delivery. A well-automated EC2 platform is infinitely better than a perfectly designed Fargate platform that’s still 6 months from production.

Auto Scaling Configuration

# Create Auto Scaling Group for Supplier Portal

aws autoscaling create-auto-scaling-group \

–auto-scaling-group-name supplier-portal-asg \

–launch-template LaunchTemplateName=supplier-portal-lt,Version=’$Latest’ \

–min-size 2 \

–max-size 10 \

–desired-capacity 2 \

–vpc-zone-identifier “subnet-,subnet-” \

–target-group-arns arn:aws:elasticloadbalancing:ap-south-1::targetgroup/supplier-portal-tg/

# Attach CPU-based scaling policy

aws autoscaling put-scaling-policy \

–auto-scaling-group-name supplier-portal-asg \

–policy-name cpu-target-tracking \

–policy-type TargetTrackingScaling \

–target-tracking-configuration ‘{

“PredefinedMetricSpecification”: {

PredefinedMetricType”: “ASGAverageCPUUtilization

},

“TargetValue”: 60.0,

“ScaleInCooldown”: 300,

“ScaleOutCooldown”: 60

}’

The same ASG pattern was applied consistently across all three applications. The ScaleOutCooldown of 60 seconds ensures rapid scale-out during production peak cycles, while the 300-second ScaleInCooldown prevents aggressive scale-in that could cause instability.

Business outcome: ~40% improvement in application availability during peak procurement cycles, with cost-efficient compute during non-peak hours.

Database Layer: Managed Resilience with Amazon RDS

All three applications used: – Amazon RDS for MySQL – Automated backups with point-in-time recovery – Multi-AZ failover for high availability – Encryption at rest via KMS

Why RDS over self-managed databases:

The customer had a single DBA managing databases for all three applications. RDS eliminated the undifferentiated heavy lifting — patching, backup management, failover configuration — and let that DBA focus on query optimization and schema design instead of server maintenance.

Business outcome: Eliminated manual backup complexity, reduced DBA operational burden by ~60%, and improved reliability with automated failover that requires zero human intervention.

Security by Design

Security controls were embedded across layers — not added as an afterthought:

Identity & Access

• IAM role-based policies with least privilege
• Separate roles per application — blast radius containment

Edge Security

• AWS WAF in front of ALB — SQL injection, XSS, bot protection
• CloudFront for content delivery and DDoS mitigation

Encryption

• AWS KMS for data encryption at rest
• Encrypted RDS storage and S3 buckets

Audit & Compliance

• CloudTrail logging for all deployment activities, IAM changes, and infrastructure updates
• Retention policies aligned with ISO audit requirements

Business outcome: All 4 ISO audit findings resolved as a byproduct of the architecture — no separate remediation project required. Audit readiness became a continuous state rather than a periodic scramble.

Disaster Recovery with AWS Elastic Disaster Recovery (DRS)

For a high-precision manufacturing enterprise, unplanned downtime is not just an IT problem — it is a production stoppage with direct revenue and contractual impact. This made structured, testable disaster recovery a non-negotiable part of the architecture, not an afterthought.

Previous State

• Manual recovery with no documented runbook
• Hours of downtime during any infrastructure failure
• No cross-region failover capability
• Backup processes dependent on individual team members

How DRS Works

AWS Elastic Disaster Recovery installs a lightweight replication agent on each source server. Once installed, the agent performs continuous block-level replication to a staging area in the secondary region (Hyderabad — ap-south-2). The recovery environment is always within minutes of the production state, not hours.

Implementation Phases

Phase 1 — Agent installation and initial sync

# Install the AWS Replication Agent on each source server (Linux)

wget -O ./aws-replication-installer-init.py \

https://aws-elastic-disaster-recovery-ap-south-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

sudo python3 aws-replication-installer-init.py \

–region ap-south-1 \

–aws-access-key-id \

–aws-secret-access-key \

–no-prompt

Replication credentials are created once in the DRS console under Settings → Replication Credentials. Never use your primary IAM credentials here — create a dedicated replication IAM user with DRS-only permissions.

Initial full sync took approximately 4–6 hours per server. After initial sync, replication is continuous and lightweight — typically under 5% of server CPU.

Phase 2 — Recovery settings configuration

For each source server: – Instance type mapping — production EC2 type matched in secondary region – Subnet and security group assignment in ap-south-2 – Launch template for recovery instances pre-configured to avoid manual steps during actual failover

Phase 3 — DR drill validation

Before going live, quarterly non-disruptive DR drills were established:

# Launch a non-disruptive DR drill — isolated instances, no production impact

aws drs start-recovery \

–source-servers ‘[{“sourceServerID”: ““}]’ \

–is-drill true \

–region ap-south-1

# Terminate drill instances once validated

aws drs terminate-recovery-instances \

–recovery-instance-ids ‘[““]’ \

–region ap-south-1

The –is-drill true flag is the most important detail here. Without it, start-recovery triggers an actual failover. The drill mode launches recovery instances in an isolated network — production traffic is completely unaffected.

RPO / RTO Achieved

The RPO achieved is significantly better than the target because DRS replicates at the block level continuously — unlike snapshot-based backups which capture state at fixed intervals.

Actual Failover Sequence

• Declare recovery event in DRS console or via CLI
• DRS launches pre-configured recovery instances in Hyderabad from latest replicated state
• DNS records updated to route traffic to secondary region
• Health checks validate application availability
• Team confirms normal operation — failover complete

Steps 1–4 are automated. Step 5 is the only human-in-the-loop action.

Business outcome: – Failover time: hours of manual recovery → < 15 minutes automated - Recovery testing: ad-hoc and untested → quarterly validated drills - Business risk: unquantified → defined, documented, and insured - Audit readiness: manual records → CloudTrail-logged failover events

A Presales Perspective: How to Sell DR to Executives

In Presales conversations, Disaster Recovery is the capability every enterprise says they want — and the first line item cut from the budget. The two objections I encounter most are: “We’ve never had a major outage” and “It sounds too complex to maintain.”

AWS Elastic DRS changed both conversations:

On complexity: The agent installs in under 30 minutes per server and replication is fully managed — there is no DR infrastructure to maintain. No separate DR environment to patch, no replication scripts to monitor, no manual sync processes.

On risk: The quarterly drill model lets customers see recovery happen before they need it. When a customer watches their application come up in a secondary region in 12 minutes during a drill, the budget conversation changes entirely.

For CFO conversations specifically: The framing that works is insurance math. Annual DRS cost for this platform: predictable monthly spend. Cost of a single 4-hour outage (production stoppage + SLA penalties + recovery labor + customer trust erosion): multiples of the annual DR investment. The question becomes: “Would you pay X/year to insure against a Y event that your current infrastructure has no protection against?” Framed as insurance, DR never loses the budget conversation.

For manufacturing enterprises specifically: The framing that resonates most is not technical — it is contractual. A single production stoppage that breaches an SLA with a Tier-1 customer costs more than the annual DRS bill. That is the business case, and it closes fast.

Monitoring & Operational Visibility

• Amazon CloudWatch — EC2 metrics, Auto Scaling activity, RDS performance, application logs
• Amazon SNS — Alert notifications and incident escalation triggers
• AWS CloudTrail — Complete audit trail for compliance

Combined, the platform delivers proactive alerting, faster MTTR, and audit-ready logging. The operations team shifted from reactive firefighting to proactive monitoring — a cultural change as significant as the technical one.

Quantitative Outcomes

The biggest transformation was not technical alone — it was operational maturity. The organization moved from “hoping nothing breaks” to “knowing exactly what happens when something does.”

Lessons for Technology Leaders

• Standardize before you optimize — Getting all three applications onto the same CI/CD pattern delivered more value than any single application optimization could have. Consistency reduces cognitive load, simplifies incident response, and accelerates onboarding.
• DR is not a technical project — it’s a business continuity investment — Frame it in contractual and revenue terms, not infrastructure terms. The CFO doesn’t care about RPO numbers — they care about SLA penalty avoidance.
• Gradual modernization beats big-bang migration — EC2 + Auto Scaling today, containers tomorrow. Deliver value incrementally and build organizational confidence with each phase.
• Quantify everything from day one — The 60% faster releases, 35% cost reduction, and <15 minute failover are what made this project referenceable. If you don’t measure the before state, you can’t prove the after state.
• Security and compliance are architecture outcomes, not separate projects — When IAM, KMS, WAF, and CloudTrail are embedded in the design, audit findings close themselves. Retrofitting security is always more expensive.

About the Author

Rajat Jindal is VP – Presales at AeonX Digital Technology Limited, where he architects winning cloud strategies for enterprise customers and translates modernization into measurable business value. He is a strong advocate of AWS, committed to sharing thought leadership that helps technology leaders make faster, better-informed decisions.

Modernizing an Enterprise CRM Platform Using Amazon ECS Fargate and AWS CI/CD

by Rajat Jindal | Jan 22, 2026 | AWS

The Modernization Imperative: Why Legacy CRM Is a Business Risk

In 2025, enterprise CRM platforms became the single largest source of unplanned downtime for mid-market companies in our customer base. Not because the business logic failed — but because the deployment and infrastructure patterns underneath them hadn’t evolved in a decade.

For technology leaders evaluating modernization, the question is no longer whether to containerize — it’s whether your current deployment model is actively costing you revenue. Every hour of deployment downtime on a customer-facing CRM is a measurable business event: missed SLAs, delayed onboarding, and support tickets that erode customer trust.

When we engaged with an enterprise running a legacy CRM and Employee Engagement platform, the symptoms were familiar: 2–3 hour deployments with downtime, hardcoded credentials, no observability, and an engineering team spending more time managing releases than building features. But the real problem wasn’t technical debt — it was business velocity. The platform’s fragility had become a constraint on how fast the organization could respond to customer needs.

This post documents that modernization — not as a step-by-step tutorial, but as a decision framework for leaders facing the same inflection point.

*The outcome:** deployment time reduced by 92%, three audit findings closed, zero-downtime releases from day one, and $180K in platform engineering budget redirected from infrastructure management to product development.*

Why This Matters Now: The Modernization Inflection Point

Three market forces are pushing enterprise CRM modernization from “nice to have” to “board-level priority”:

• Customer experience expectations have shifted — B2B buyers now expect the same responsiveness from supplier portals that they get from consumer apps. A CRM that goes down for 2 hours during a deployment is no longer acceptable to customers who compare every digital interaction to their best consumer experience.
• Talent retention depends on developer experience — Engineering teams leave organizations where deployments are manual, risky, and slow. In a competitive hiring market, modernization is as much a talent strategy as a technology strategy. The engineers you want to retain are the ones who refuse to tolerate manual deployment processes.
• Compliance and audit pressure is increasing — Hardcoded credentials and no audit trail were tolerable five years ago. Today they’re audit findings that delay deals, increase cyber insurance premiums, and create personal liability for technology leaders who sign off on compliance attestations.

The decision to modernize this platform was driven by all three — not by a technology team wanting newer tools, but by business leadership recognizing that the current state was a competitive liability.

The Business Problem

The existing system had:

• 2–3 hour deployments with downtime during business hours
• No CI/CD automation — releases required coordinated manual effort
• Hardcoded credentials — an active audit risk
• No centralized logging — incident response was reactive and slow
• No scalability — performance degraded during peak usage periods

Business impact of the status quo:

• Customer-facing CRM unavailable during every release window
• Senior engineers spending ~20% of their time on deployment coordination instead of product development
• 3 open audit findings related to credential management and change control
• Customer complaints during peak periods with no ability to scale

The goal was not lift-and-shift, but true cloud-native modernization that addressed business risk, not just technical debt.

Target Architecture

Target Architecture Diagram – Modernizing Enterprise CRM with ECS Fargate and End-to-End CI/CD on AWS

AWS Services Used:

• Amazon ECS (Fargate) — serverless container compute
• Amazon RDS for MySQL — managed database with Multi-AZ
• Amazon S3 — frontend hosting
• AWS CodePipeline, CodeBuild, CodeDeploy — CI/CD automation
• Amazon ECR — container image registry
• AWS Secrets Manager — credential management
• Amazon CloudWatch & CloudTrail — observability and audit
• AWS WAF — web application firewall
• AWS KMS — encryption at rest
• Amazon SNS — alerting and notifications

Key Strategic Decisions

These are the decisions that shaped the architecture — and the business reasoning behind each one.

Decision 1: Why Fargate Over EKS or EC2?

As a Presales professional evaluating modernization options with enterprise customers, the decision point I see most often is not Fargate vs EC2 — it’s Fargate vs EKS.

Customers often arrive with EKS already in mind — drawn by its flexibility and ecosystem. But for most enterprise web applications and APIs, that flexibility comes at the cost of months of platform engineering. Fargate removes that burden entirely, letting teams focus on shipping features rather than managing cluster nodes.

The business decision: Fargate eliminated an entire hiring requirement. The customer had budgeted for a platform engineering hire to manage Kubernetes — Fargate removed that need entirely, redirecting ~$180K annually toward feature development instead of infrastructure management. Unless a customer has strong Kubernetes expertise in-house or needs advanced scheduling, Fargate is almost always the faster path to production — and the safer recommendation.

Decision 2: Why Blue/Green Over In-Place Deployment?

In-place deployments are simpler to configure — CodeDeploy stops the old version, installs the new one, and restarts. For non-critical internal tools, that simplicity is acceptable. For a CRM handling active user sessions, in-place deployment creates a hard problem: the application is unavailable during the swap window, and there is no fast rollback path if the new version fails.

Blue/Green deployment eliminates both risks:

• The new version is deployed to a fresh task set and validated by ALB health checks before a single user request touches it
• Traffic switches in one atomic operation — a listener rule update on the ALB
• If anything fails post-switch, rollback is equally instant: point the listener back at the blue environment
• No re-deployment, no downtime, no manual intervention

The business decision: Zero-downtime deployment is not a DevOps preference — it’s a customer experience decision. The approximately 5-minute overhead of spinning up a parallel task set is the only cost. For an enterprise CRM where a failed deployment during business hours directly affects customer-facing operations, that trade-off closes in seconds. Frame it that way in your business case and it gets funded faster.

Decision 3: Why Secrets Manager Over Parameter Store?

Both AWS Secrets Manager and Systems Manager Parameter Store can store credentials securely, and Parameter Store is free for standard parameters. We chose Secrets Manager for three specific reasons:

• Automatic secret rotation on a defined schedule without any application code change
• Native RDS integration to rotate database passwords automatically
• Dedicated audit trail in CloudTrail logging every secret access event

The business decision: For a CRM handling customer PII, a credential that auto-rotates every 30 days has a fundamentally smaller blast radius than one that relies on manual rotation discipline. This directly addressed two of the three open audit findings — closing them as a byproduct of good architecture rather than a separate remediation project.

Implementation Pattern

The implementation followed a standard containerization and CI/CD pattern. The specifics are below for practitioners, but the strategic decisions above are what differentiate this from a generic container deployment.

Containerization

FROM node:18

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD [“npm”, “start”]

ECR Image Push

aws ecr create-repository –repository-name crm-app

aws ecr get-login-password –region ap-south-1 | \

docker login –username AWS –password-stdin .dkr.ecr.ap-south-1.amazonaws.com

docker build -t crm-app .

docker tag crm-app:latest .dkr.ecr.ap-south-1.amazonaws.com/crm-app:latest

docker push .dkr.ecr.ap-south-1.amazonaws.com/crm-app:latest

ECS Fargate Task Definition

{

“family”: “crm-task”,

“networkMode”: “awsvpc”,

“requiresCompatibilities”: [“FARGATE”],

“cpu”: “1024”,

“memory”: “2048”,

“executionRoleArn”: “arn:aws:iam:::role/ecsTaskExecutionRole”,

“containerDefinitions”: [

{

“name”: “crm-container”,

“image”: ““,

“portMappings”: [

{ “containerPort”: 3000 }

],

“secrets”: [

{

“name”: “DB_PASSWORD”,

valueFrom”: “arn:aws:secretsmanager:ap-south-1::secret:crm-db

}

]

}

]

}

CI/CD Pipeline (CodePipeline + CodeBuild + CodeDeploy)

Pipeline Flow: GitHub → CodePipeline trigger → CodeBuild (build & push Docker image) → CodeDeploy (Blue/Green deployment to ECS)

# buildspec.yml

version: 0.2

phases:

pre_build:

commands:

• aws ecr get-login-password –region ap-south-1 | docker login –username AWS –password-stdin $REPO_URI

build:

commands:

• docker build -t crm-app .
• docker tag crm-app:latest $REPO_URI:latest

post_build:

commands:

• docker push $REPO_URI:latest

Secrets Management

aws secretsmanager create-secret \

–name crm-db \

–secret-string ‘{“username”:”admin”,”password”:”your-secure-password”}’

Injected into ECS tasks securely — no hardcoding. Never use real credentials in CLI examples — use environment variables or a vault reference.

Security Architecture

Security controls were embedded across layers, not bolted on after deployment:

• Identity & Access: IAM task roles with least privilege, role-based CI/CD permissions
• Network Segmentation: Public subnets (ALB only), private subnets (ECS + RDS), Security Groups for micro-segmentation
• Edge Protection: AWS WAF in front of ALB to protect against SQL injection, XSS, and malicious bot traffic
• Encryption: AWS KMS for data at rest (RDS + S3), TLS for data in transit
• Audit: CloudTrail for API logging, enabling compliance traceability

Business impact: For a CRM platform handling customer and employee data, WAF and KMS are non-negotiable layers. Combined with Secrets Manager for credentials, this eliminates all plaintext sensitive data from the system — resolving the audit findings that had been open for 18 months.

Observability and Operational Maturity

• CloudWatch Logs → application logs with structured queries
• CloudWatch Alarms → CPU, memory, deployment health — published to SNS for immediate team notification
• CloudTrail → API auditing for compliance
• Amazon SNS → routes alerts to on-call engineering via email and SMS

This ensures the right people are notified immediately when thresholds breach — without anyone manually watching dashboards. The result: faster MTTR and proactive monitoring instead of reactive firefighting.

Common Pitfalls (Real Lessons)

These are not theoretical — each one caused at least one failed deployment during the implementation. Document them in your runbook.

Business Outcomes

The real ROI is not infrastructure cost savings — it’s the engineering capacity freed up and the customer experience risk eliminated. The 80% reduction in manual operations freed senior engineers for product work. Customer-reported downtime incidents during release windows dropped from an average of 3–4 per month to zero — and support ticket volume related to platform availability fell by over 60% within the first quarter post-modernization. That’s the real ROI, not the compute bill.

Developer Experience Transformation

Before Modernization

• Developers manually shared builds with operations teams
• Deployments required coordinated downtime windows
• Debugging required direct server access
• Releases were infrequent and risky — creating a culture of fear around change

After Modernization

• Developer pushes code to GitHub
• CodePipeline triggers automatically
• CodeBuild builds, creates Docker image, runs validations
• Image pushed to ECR
• CodeDeploy deploys via Blue/Green, validates health checks
• Success → deployment completes | Failure → automatic rollback

Developers no longer “request deployments” — they trigger them with every commit.

This shift matters beyond efficiency. When deployments are safe and fast, teams ship smaller changes more frequently. Smaller changes are easier to debug, easier to rollback, and lower risk. The cultural shift from “big scary releases” to “continuous safe delivery” is the most valuable outcome of this entire modernization — and the hardest to quantify on a spreadsheet.

Future Evolution Roadmap

Modernization is not a one-time project — it’s a continuous journey. This architecture establishes a strong foundation, but true cloud maturity comes from continuous optimization, automation expansion, and security evolution.

Building the Business Case: What Resonates with Executive Stakeholders

In enterprise presales, the most common objection to modernization is not technical — it’s “we don’t have time to stop and rebuild.” The architecture pattern in this post directly addresses that objection because it’s incremental: containerize first, automate deployment second, add observability third. No big-bang rewrite required.

When I present this pattern to CTO/VP Engineering audiences, the moment that shifts the conversation is the deployment time comparison: 2–3 hours with downtime → 10 minutes with zero downtime. That’s not a technology metric — it’s a business agility metric that every executive understands immediately.

The second moment is the security conversation. When a CISO hears “hardcoded credentials in config files,” the room gets uncomfortable. When they hear “Secrets Manager with automatic 30-day rotation and CloudTrail audit logging,” the compliance conversation is over. Security modernization sells itself — you just have to surface the current-state risk clearly enough.

For technology leaders evaluating this pattern: the question is not “can we afford to modernize?” It’s “can we afford the next audit finding, the next deployment outage, or the next senior engineer who leaves because they’re tired of manual releases?”

Lessons for Technology Leaders

• Modernization ROI is not just infrastructure cost — The 80% reduction in manual operations freed senior engineers for product work. That’s the real ROI, not the compute bill.
• Zero-downtime deployment is a customer experience decision, not a DevOps preference — Frame it that way in your business case and it gets funded faster.
• The “Fargate vs EKS” decision is really a “build platform team vs ship features” decision — Unless you have Kubernetes expertise in-house already, Fargate gets you to production months faster.
• Start with CI/CD, not containers — Containerization without automated deployment just gives you a more complex manual process. The pipeline is the real accelerator.
• Security modernization pays for itself in audit avoidance — Every open finding has a cost. Closing them through good architecture is cheaper than remediating them separately.

*About the Author** *

Rajat Jindal is VP – Presales at AeonX Digital Technology Limited, where he architects winning cloud strategies for enterprise customers and translates modernization into measurable business value. He is a strong advocate of AWS, committed to sharing thought leadership that helps technology leaders make faster, better-informed decisions.