🏗️ Introduction

In this guide, we build a production-grade AWS architecture where ECS microservices communicate internally through Cloud Map service discovery, inside private subnets, behind a private ALB, with a public NLB at the edge.

We use:

• ECS (awsvpc mode)

• Cloud Map (Private DNS)

• Route 53 Private Hosted Zone

• Internal ALB (private)

• Public NLB (public)

• Spring Boot microservices (Service A & B)

And most importantly:

Service B → http://service-a.local:8080/

works internally across ECS tasks.

🗺️ High-Level Architecture Diagram

CLIENT → Public NLB (Public Subnets)
              │
              ▼
      Internal ALB (Private Subnets)
              │
      ┌───────┼────────┐
      │        │        │
 Service A   Service B   (More Services)
 (ECS)       (ECS)

Cloud Map Private DNS Namespace: "local"
 ├── service-a.local
 └── service-b.local

Route 53 Private Hosted Zone (Auto-created by Cloud Map)

🟦 VPC Requirements Checklist

• VPC with DNS support enabled

• Private subnets for ALB and ECS

• Public subnets for NLB

• NAT (if needed for outbound)

• Correct routing and NACLs

🟩 ECS Checklist

• ECS cluster deployed

• awsvpc mode enabled

• Tasks receive ENI in private subnets

• Port 8080 exposed

• Containers listen on 0.0.0.0:8080

🟥 Cloud Map Checklist (Service Discovery)

• Private DNS namespace local created

• Route 53 private hosted zone auto-created

• A-records registered for both services

• ECS service registry attached

• Service instances show Healthy

• DNS resolves internally

• TTL = 10 seconds

🟧 Security Group Checklist (Very Important)

• ALB SG → ECS SG (8080)

• NLB SG → ALB SG (443/80)

• ECS SG → ECS SG (self reference on port 8080)

Example rule:

resource "aws_security_group_rule" "ecs_internal_8080" {
  type              = "ingress"
  from_port         = 8080
  to_port           = 8080
  protocol          = "tcp"
  security_group_id = aws_security_group.ecs_tasks_sg.id
  self              = true
}

This allows Service A ↔ Service B communication inside the same SG.

🟪 Cloud Map Terraform Snippets (Insert in Post)

Private DNS Namespace

resource "aws_service_discovery_private_dns_namespace" "local" {
  name = "local"
  vpc  = var.vpc_id
}

Service A Cloud Map Entry

resource "aws_service_discovery_service" "svc_a" {
  name = "service-a"

  dns_config {
    namespace_id = aws_service_discovery_private_dns_namespace.local.id
    dns_records {
      type = "A"
      ttl  = 10
    }
  }

  health_check_custom_config {
    failure_threshold = 1
  }
}

Service B Cloud Map Entry

resource "aws_service_discovery_service" "svc_b" {
  name = "service-b"

  dns_config {
    namespace_id = aws_service_discovery_private_dns_namespace.local.id
    dns_records {
      type = "A"
      ttl  = 10
    }
  }

  health_check_custom_config {
    failure_threshold = 1
  }
}

ECS Service Registry Attachment

service_registries {
  registry_arn = aws_service_discovery_service.svc_a.arn
  port         = 8080
}

🟫 Insert Cloud Map Namespace Screenshot

\>

🟫 Insert Cloud Map Service A Instance Screenshot

🟫 Insert Cloud Map Service B Instance Screenshot

🟫 Insert Route 53 Private Hosted Zone Screenshot

🟧 Internal ALB Checklist

• Private subnets only

• ALB SG allows NLB inbound

• ALB → ECS target groups

• Health checks to /actuator/health

🟦 Public NLB Checklist

• Public subnets

• Listener forwards to internal ALB

• TLS termination (optional)

• No ECS directly exposed

🟨 Java Microservices

Service A (Simple)

@RestController
@SpringBootApplication
public class ServiceAApplication {

    @GetMapping("/")
    public String hello() {
        return "Hello from Service A";
    }

    public static void main(String[] args) {
        SpringApplication.run(ServiceAApplication.class, args);
    }
}

Service B (Calls A Every 5 Seconds)

@EnableScheduling
@SpringBootApplication
public class ServiceBApplication {

    private static final Logger log = LoggerFactory.getLogger(ServiceBApplication.class);
    private static final String URL = "http://service-a.local:8080/";

    @Bean
    public RestTemplate restTemplate() { return new RestTemplate(); }

    @Scheduled(fixedDelay = 5000)
    public void callServiceA() {
        log.info("Calling Service A at {}", URL);
        try {
            RestTemplate rt = restTemplate();
            String resp = rt.getForObject(URL, String.class);
            log.info("Response from Service A: {}", resp);
        } catch (Exception ex) {
            log.error("Failed: {}", ex.getMessage());
        }
    }
}

🟩 ECS Exec Validation (Logs)

Calling Service A at http://service-a.local:8080/
Response from Service A: Hello from Service A

🏁 Conclusion

You now have:

• Fully private microservices

• Service discovery via Cloud Map

• Route 53 Private Hosted Zone DNS

• Internal ALB

• External NLB

• ECS internal communication working

• Verified traffic with ECS Exec

• Java microservices talking internally

🔗 GitHub Repository

📦 GitHub Repository

You can find the complete Terraform code, reusable modules, and deployment steps for this architecture in my GitHub repository:

👉 GitHub Repo:
https://github.com/prince097cloud-architect/ecs-fargate-microservices

This repository includes:

• Full ECS on Fargate setup

• Cloud Map–based private service discovery

• Internal ALB + Public NLB routing

• Microservice A & B with path-based routing

• Complete Terraform IaC with modular structure

• End-to-end deployment instructions

Feel free to ⭐ star the repo if you find it helpful!

🤝 Connect With Me on LinkedIn

💬 Connect with Me for More Cloud & Serverless Content

I regularly share deep-dive content on:

• AWS Cloud Architecture

• Serverless + Fargate patterns

• ECS networking

• Terraform best practices

• AI + Cloud Engineering workflows

If you enjoyed this post, let’s connect:

👉 LinkedIn:
https://www.linkedin.com/in/prince97/

Happy to connect with fellow engineers, cloud builders, and serverless enthusiasts!

1. AWS Architecture Overview

Our setup simulates a production environment:

1. Enterprise VM / Oracle VM: Generates files/data to be uploaded to S3.

2. AWS S3 Bucket: Configured with KMS encryption, versioning, and public access restrictions.

3. Agentic AI: Acts as a cloud assistant, allowing architects to:

   • List all S3 buckets

   • Check bucket security and compliance

   • Provide recommendations

Key Highlights:

• Files that do not meet KMS encryption requirements fail to upload.

• Ensures compliance before data reaches production.

• Fully automated, agent-driven security insights.

Architecture diagram showing Enterprise VM → S3 → Agentic AI → Security reports

2. Agentic AI Workflow

The Agentic AI agent interacts with AWS services dynamically:

1. User Query Input: Architects can ask questions like:

   • “List all S3 buckets”

   • “What is the security status of this bucket?”

2. AWS Action Registry: Functions dynamically call AWS services (S3, KMS, IAM).

3. LLM Integration: Summarizes AWS findings in human-readable, actionable insights.

4. Recommendations Output: Provides clear next steps:

   • Enable KMS for encryption

   • Fix public access issues

   • Add versioning or bucket policies

3. Example S3 Security Findings

This is the sample output:

Bucket: secure-dataflow-raw-bucket

• Issues Identified: Public access allowed in bucket policy.

• Public Access: Blocked effectively

• Versioning: Enabled

• Encryption: KMS applied

• Recommendations: Restrict bucket policy, review policies regularly

Key Insights:

• Versioning is enabled on all buckets (good for recovery).

• Encryption practices vary; some buckets need KMS.

• Regular review of bucket policies is crucial.

What is NEXT?????

Next-Level Preventive Measures (Pre-Validation Agentic AI)

Beyond monitoring, we’re implementing Agentic AI for pre-validation:

• Continuous S3 Log Scanning: Detects misconfigured uploads before reaching production.

• Preventive Alerts: Warns users if a file violates encryption, access, or policy rules.

• Automated Compliance Checks: Confirms versioning, KMS, and bucket policies are in place.

• Enterprise Benefits:

  • Prevents insecure files from entering production

  • Reduces human errors

  • Gives architects confidence in cloud security

Enterprise Value & Scalability

• Automated Compliance: Real-time checks remove the need for manual inspection.

• Actionable AI Insights: LLM summaries convert raw AWS data into easy-to-read recommendations.

• Future Extensions:

  • Extend to EC2, IAM, Lambda, and RDS

  • Scheduled scans and dashboards for monitoring

  • Cost estimation per bucket/day

Conclusion:
Agentic AI demonstrates how AI-driven security and preventive validation can transform enterprise cloud operations, making production deployments safer, faster, and more reliable.

Repository & Resources:

• [GitHub Repo] – GitHub

• [LinkedIn Profile] – Lets Connect