Introduction

Modern cloud architectures often involve multiple VPCs to separate concerns, improve security, and maintain organizational boundaries. However, this segmentation creates challenges when services need to communicate across VPC boundaries. In this post, I’ll walk through a proof of concept (POC) that demonstrates how AWS VPC Lattice can elegantly solve this problem for a payment gateway service.

The Problem: Cross-VPC Communication

Imagine you’re building a payment processing system with these requirements:

1. The payment gateway service must run in an isolated VPC for enhanced security
2. Multiple applications in different VPCs need to access the payment service
3. The solution must be scalable, secure, and have minimal network configuration overhead
4. External clients need access to the payment APIs through a standardized interface

Traditional solutions like VPC peering or Transit Gateway work but require complex networking configuration and don’t provide service discovery or traffic management capabilities.

VPC Lattice Payment Gateway Service: Use Case and API Summary

Use Case Summary

This proof of concept demonstrates how AWS VPC Lattice enables secure service-to-service communication across different VPCs without requiring complex
networking configurations:

1. Cross-VPC Service Communication: A Payment Gateway Service runs on ECS in SpokeC-vpc, while a Lambda function in SpokeA-vpc calls this service
   through VPC Lattice.
2. Public API Exposure: API Gateway exposes the Payment Gateway Service APIs to the public internet, allowing external clients to interact with the
   service.
3. Service Discovery: VPC Lattice provides service discovery and DNS resolution, allowing the Lambda function to find and communicate with the Payment
   Gateway Service using a consistent endpoint.
4. Network Isolation: Each service remains in its own VPC with appropriate security controls, while still being able to communicate with other services.

Payment Gateway Service API Reference

Health Check Endpoints

• GET /health
• Purpose: Quick health status check of the service and its payment gateways
• Response: Basic health status information

• GET /health/deep
• Purpose: Comprehensive health check of all service components
• Response: Detailed health status of each component

Payment Gateway Management

• GET /api/gateways
• Purpose: Retrieve information about available payment processors
• Response: List of payment gateways with their capabilities and status

• POST /api/process-payment
• Purpose: Process a payment transaction through a specified gateway
• Request Body:

json
{
“amount”: 600.00,
“currency”: “USD”,
“gateway”: “paypal”,
“payment_method”: “paypal_balance”,
“metadata”: {
“order_id”: “12346”
}
}

• Response: Transaction details including status and confirmation

Monitoring and Analytics

• GET /api/metrics
• Purpose: Retrieve payment processing statistics and performance metrics
• Response: Metrics on transaction volume, success rates, and processing times

Currency Services

• GET /api/exchange-rate/usd-inr
• Purpose: Get current exchange rate between USD and INR
• Response:

Architecture Benefits

• Simplified Connectivity: VPC Lattice eliminates the need for complex VPC peering, Transit Gateways, or NAT configurations
• Enhanced Security: Traffic between services remains within the AWS network and can be controlled with fine-grained policies
• Scalability: Services can scale independently in their respective VPCs
• Reduced Operational Overhead: No need to manage networking infrastructure like load balancers or proxies
• Consistent API Access: The same APIs can be accessed through multiple paths (API Gateway, Lambda, direct VPC Lattice)

This architecture demonstrates how modern microservices can be deployed across different network boundaries while maintaining secure and efficient
communication patterns.

Why ECS Fargate?

ECS Fargate was selected as the compute platform for our payment gateway service for several compelling reasons:

1. Containerized Deployment – Containerization provides consistency across environments and simplifies deployment
2. Serverless Operations – Fargate eliminates the need to manage underlying EC2 instances
3. Scalability – Fargate can automatically scale based on demand, essential for payment processing workloads
4. Security Isolation – Each task runs in its own isolated environment
5. Cost Efficiency – Pay only for the resources used by the containers
6. VPC Integration – Fargate tasks can be deployed within VPCs, making them ideal for VPC Lattice connectivity testing

The Complete Architecture Story

Our architecture simulates a common enterprise scenario where:

1. A payment processing service runs in a dedicated VPC (SpokeC-vpc) with specific security controls
2. Business logic services run in separate VPCs (SpokeA-vpc) and need to communicate with the payment service
3. External clients need access to payment APIs through a public endpoint

VPC Lattice elegantly solves this communication challenge by:

1. Providing service discovery across VPC boundaries
2. Enabling secure service-to-service communication
3. Eliminating the need for complex networking configurations
4. Allowing fine-grained access control between services

By implementing this mock payment gateway on ECS Fargate and connecting it through VPC Lattice, we’ve created a realistic demonstration that showcases
how modern AWS networking can simplify complex enterprise architectures while maintaining security and operational efficiency.

Enter AWS VPC Lattice

AWS VPC Lattice is a service networking solution that simplifies how services communicate across VPCs and accounts. It provides:

• Service discovery
• Traffic management
• Access control
• Observability

Let’s see how we can use VPC Lattice to build our payment gateway service.

Architecture Overview

VPC Lattice Components in Our Architecture

Our payment gateway POC leverages several key VPC Lattice components to enable seamless cross-VPC communication:

1. VPC Lattice Service Network

The service network acts as the central connectivity fabric that binds our VPCs together:
• Creates a logical boundary for service communication
• Enables service discovery across VPC boundaries
• Provides DNS-based service resolution
• Applies consistent security policies across all services

2. VPC Lattice Service

The VPC Lattice service represents our payment gateway application:
• Provides a stable DNS endpoint for service discovery
• Handles traffic routing to the ECS Fargate tasks
• Enables health checking of backend targets
• Supports TLS termination for secure communication

3. VPC Lattice Service Associations

Service associations connect our VPCs to the service network:
• Links SpokeA-vpc and SpokeC-vpc to the service network
• Enables the Lambda function in SpokeA-vpc to discover and communicate with the ECS service in SpokeC-vpc
• Maintains security group isolation between VPCs

4. VPC Lattice Listeners and Target Groups

Listeners and target groups route traffic to our payment service:
• Listeners define the protocols and ports for incoming traffic
• Target groups direct traffic to the ECS Fargate tasks
• Health checks ensure traffic only goes to healthy instances

Detailed Architecture Diagram

VPC Lattice Configuration Snapshots

Service Network Configuration

json
{
“Name”: “payment-service-network”,
“Id”: “sn-0a1b2c3d4e5f6g7h8”,
“Arn”: “arn:aws:vpc-lattice:us-east-1:123456789012:servicenetwork/sn-0a1b2c3d4e5f6g7h8”,
“AuthType”: “AWS_IAM”,
“DnsEntry”: {
“DomainName”: “payment-service-network.sn-0a1b2c3d4e5f6g7h8.us-east-1.vpc-lattice.amazonaws.com”,
“HostedZoneId”: “Z01234567ABCDEFGHIJKL”
}
}

VPC Lattice Service Configuration

json
{
“Name”: “payment-gateway-service”,
“Id”: “svc-0a1b2c3d4e5f6g7h8”,
“Arn”: “arn:aws:vpc-lattice:us-east-1:123456789012:service/svc-0a1b2c3d4e5f6g7h8”,
“Status”: “ACTIVE”,
“DnsEntry”: {
“DomainName”: “payment-gateway-service.svc-0a1b2c3d4e5f6g7h8.us-east-1.vpc-lattice.amazonaws.com”,
“HostedZoneId”: “Z01234567ABCDEFGHIJKL”
},
“AuthType”: “NONE”
}

VPC Association Configuration

json
{
“ServiceNetworkId”: “sn-0a1b2c3d4e5f6g7h8”,
“VpcId”: “vpc-06bb9f3453465ee95”,
“Id”: “snva-0a1b2c3d4e5f6g7h8”,
“Status”: “ACTIVE”,
“CreatedAt”: “2025-07-01T10:00:00.000Z”,
“SecurityGroupIds”: [“sg-0a1b2c3d4e5f6g7h8”]
}

Key Benefits of VPC Lattice in Our Payment Gateway POC

1. Simplified Service Discovery: Services can find each other using DNS names without complex networking
2. Enhanced Security: Traffic between services remains within the AWS network and can be controlled with IAM policies
3. Reduced Operational Overhead: No need to manage networking infrastructure like load balancers or proxies
4. Scalability: Services can scale independently in their respective VPCs
5. Observability: Built-in monitoring and logging for service-to-service communication

Implementation Highlights

Our payment gateway POC demonstrates how VPC Lattice enables:

1. Cross-VPC Service Communication: The Lambda function in SpokeA-vpc seamlessly communicates with the ECS service in SpokeC-vpc
2. Service Discovery: The Lambda function uses the VPC Lattice DNS name to discover the payment service
3. Security Isolation: Each service remains in its own VPC with appropriate security controls
4. API Gateway Integration: External clients can access the payment service through API Gateway, which forwards requests to the Lambda function

This architecture showcases how VPC Lattice simplifies complex networking challenges while maintaining security and operational efficiency in a payment
processing context.

I need some story with VPC lattice compoments for the blogs

Building a Secure Payment Gateway Architecture with AWS VPC Lattice

The Challenge: Secure Cross-VPC Communication for Payment Processing

When our team set out to modernize our payment processing infrastructure, we faced a common challenge in distributed architectures: how to securely
connect services across different VPCs while maintaining strict network isolation for our payment processing components.

Traditional solutions like VPC peering or Transit Gateway would have required complex routing configurations and security group management. We needed a
simpler approach that would maintain security while reducing operational overhead.

Enter VPC Lattice: Service Networking Simplified

AWS VPC Lattice provided the perfect solution for our payment gateway architecture. Let’s explore how the key VPC Lattice components enabled our secure
payment processing system:

VPC Lattice Service Network: The Foundation

The VPC Lattice service network became the backbone of our architecture, creating a logical connectivity layer that spans our VPCs:

Service Network: payment-network
Region: us-east-1
Auth Type: AWS_IAM

This service network allowed us to:
• Define a clear boundary for service communication
• Apply consistent access policies across all services
• Enable service discovery between our payment components

VPC Lattice Service: The Payment Gateway

We registered our payment gateway ECS service with VPC Lattice, creating a discoverable endpoint:

Service Name: payment-gateway-service
DNS: payment-gateway-service.svc-0a1b2c3d4e5f6g7h8.us-east-1.vpc-lattice.amazonaws.com
Protocol: HTTPS
Port: 443

This service definition:
• Provided a stable DNS endpoint for our payment gateway
• Enabled TLS encryption for all payment traffic
• Simplified service discovery for client applications

VPC Associations: Connecting Our Network Segments

We associated both our VPCs with the service network:

VPC Associations:

• SpokeA-vpc (vpc-06bb9f3453465ee95): Contains Lambda clients
• SpokeC-vpc (vpc-09e69971ba778dc66): Hosts payment gateway ECS service

These associations:
• Enabled the Lambda function to discover the payment service
• Maintained network isolation between VPCs
• Eliminated the need for complex routing configurations

Service Policies: Enforcing Least Privilege

We implemented VPC Lattice service policies to enforce strict access controls:

json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::123456789012:role/payment-client-lambda-role”
},
“Action”: “vpc-lattice-svcs:Invoke”,
“Resource”: “*”,
“Condition”: {
“StringEquals”: {
“vpc-lattice-svcs:ServiceNetworkArn”: “arn:aws:vpc-lattice:us-east-1:123456789012:servicenetwork/sn-0a1b2c3d4e5f6g7h8”
}
}
}
]
}

This policy ensures:
• Only authorized Lambda functions can call the payment service
• Access is restricted to specific API operations
• All access attempts are logged for audit purposes

The Results: A Secure, Scalable Payment Architecture

By leveraging VPC Lattice components, we created a payment gateway architecture that:

1. Maintains Security: Payment processing services remain in isolated VPCs with strict access controls
2. Simplifies Operations: No need to manage complex networking infrastructure
3. Enables Scalability: Services can scale independently in their respective VPCs
4. Improves Observability: Built-in monitoring for all service-to-service communication

Our ECS Fargate-based payment gateway service now processes transactions securely while being accessible to authorized services across our AWS
environment. The Lambda function in SpokeA-vpc communicates seamlessly with the payment service in SpokeC-vpc, all without complex networking
configurations.

API Showcase: The Payment Gateway in Action

Our payment gateway exposes several APIs through VPC Lattice:

GET /health – Service health check
GET /api/gateways – Available payment processors
POST /api/process-payment – Process a payment transaction
GET /api/metrics – Payment processing statistics
GET /api/exchange-rate/usd-inr – Currency exchange rates

These APIs are accessible to authorized services through VPC Lattice, and to external clients through our API Gateway integration.

VPC Lattice as a Game-Changer

VPC Lattice has transformed how we approach service networking for payment processing. By providing a simple, secure way to connect services across VPC
boundaries, it has enabled us to build a more resilient and maintainable payment architecture.

For organizations looking to modernize their payment infrastructure while maintaining strict security controls, VPC Lattice offers a compelling
solution that reduces complexity while enhancing security and scalability.

Our architecture consists of:

1. Payment Gateway Service: An ECS Fargate service running in SpokeC-vpc
2. Client Lambda Function: A Lambda function in SpokeA-vpc that calls the Payment Gateway Service
3. VPC Lattice: Connects the Lambda function to the ECS service across VPC boundaries
4. API Gateway: Exposes the payment APIs to external clients

Implementation Details

Payment Gateway Service

The Payment Gateway Service is a Flask application running on ECS Fargate that provides these endpoints:

• /health and /health/deep: Health check endpoints
• /api/gateways: Lists available payment gateways
• /api/process-payment: Processes payments
• /api/metrics: Provides payment processing metrics
• /api/exchange-rate/usd-inr: Gets the current USD to INR exchange rate

Client Lambda Function

The Lambda function acts as a bridge between API Gateway and the Payment Gateway Service. It:

1. Receives requests from API Gateway
2. Forwards them to the Payment Gateway Service through VPC Lattice
3. Returns the responses back to API Gateway

VPC Lattice Configuration

VPC Lattice creates a service network that connects the Lambda function’s VPC (SpokeA-vpc) to the ECS service’s VPC (SpokeC-vpc). This allows the Lambda function to call the ECS service using a DNS name, without any direct network connectivity between the VPCs.

API Gateway Integration

API Gateway provides a public endpoint for the payment APIs. It forwards requests to the Lambda function, which then communicates with the Payment Gateway Service through VPC Lattice.

Use Cases for This Architecture

1. Multi-tenant SaaS Applications

If you’re building a SaaS application where each tenant has their own VPC, VPC Lattice allows you to provide centralized services (like payments) that all tenants can access without complex networking.

2. Microservices Architecture

In a microservices architecture, you might have different teams managing different services in separate VPCs. VPC Lattice enables these services to communicate while maintaining isolation.

3. Payment Processing as a Service

If you’re offering payment processing as a service to multiple applications or customers, this architecture allows you to:

• Keep the payment service in a highly secure, isolated VPC
• Provide access to multiple clients in different VPCs
• Maintain centralized control over access policies
• Monitor and observe all traffic to the payment service

4. Regulatory Compliance

For industries with strict regulatory requirements (like finance or healthcare), this architecture helps by:

• Isolating sensitive payment processing in a dedicated VPC
• Providing fine-grained access control through VPC Lattice policies
• Enabling comprehensive logging and monitoring
• Simplifying compliance audits by centralizing service access

Benefits of This Approach

1. Simplified Networking: No need to manage complex VPC peering or Transit Gateway configurations
2. Enhanced Security: Fine-grained access control at the service level
3. Improved Observability: Centralized monitoring of cross-VPC traffic
4. Scalability: Easy to add new consumers in different VPCs
5. Reduced Operational Overhead: Service discovery and DNS-based routing handled by VPC Lattice

Personal Experience and Challenges

Implementing this POC was not without its challenges. One of the most significant hurdles we faced was getting the ECS service to reach a steady state. Here’s what we encountered:

ECS Service Steady State Issues

1. IAM Role Permissions: Initially, our ECS tasks failed to launch with the error: “ECS was unable to assume the role that was provided for this task.” We had to carefully review and adjust the trust relationships in our IAM roles to ensure ECS could assume them properly.
2. Security Group Configuration: We encountered errors related to security groups that didn’t exist or had incorrect permissions. This required careful auditing of our security group configurations and ensuring they allowed the necessary traffic between VPC Lattice and our ECS tasks.
3. Task Definition Compatibility: We faced issues with task definition compatibility, particularly with network mode settings and container definitions. Ensuring that our task definitions were properly configured for Fargate and VPC Lattice integration took several iterations.
4. Network Connectivity: Even after the ECS service was running, we faced connectivity issues between the Lambda function and the ECS service through VPC Lattice. The Lambda function would time out when trying to connect to the ECS service. We had to implement a fallback mechanism using mock implementations in the Lambda function while troubleshooting the network connectivity issues.
5. Service Discovery: VPC Lattice service discovery wasn’t working as expected initially. We had to ensure that the DNS settings were properly configured and that the service was registered correctly with VPC Lattice.
6. Deployment Stability: During updates, we noticed that the ECS service would sometimes fail to reach a steady state after deploying new container images. We had to implement proper health checks and adjust the deployment configuration to ensure smooth updates.

These challenges taught us valuable lessons about the intricacies of ECS, VPC Lattice, and cross-VPC communication. They also highlighted the importance of thorough testing and monitoring when implementing such architectures.

Challenges and Considerations

While implementing this POC, I encountered a few additional challenges:

1. Network Connectivity: Ensuring proper security group configurations for VPC Lattice endpoints
2. Error Handling: Implementing robust error handling for cross-VPC communication
3. Latency: Monitoring and optimizing for potential latency in cross-VPC calls
4. Authentication: Implementing proper authentication between services

Code Examples

Here’s how the Lambda function forwards requests to the Payment Gateway Service through VPC Lattice:

python
def lambda_handler(event, context):
“””
Lambda handler that processes API Gateway events and forwards requests to the payment gateway service.
“””
## Extract path and HTTP method from the API Gateway event
path = event.get(‘path’, ”)
http_method = event.get(‘httpMethod’, ‘GET’)
body = event.get(‘body’)

## Construct the URL using VPC Lattice DNS
url = f”http://{PAYMENT_SERVICE_DNS}{path}”

try:
# Create the request
request = urllib.request.Request(url, method=http_method)
request.add_header(‘Content-Type’, ‘application/json’)

   # Add the body for POST requests
   if http_method == 'POST' and body:
       request.data = json.dumps(body).encode('utf-8')

   # Send the request through VPC Lattice
   response = urllib.request.urlopen(request, timeout=10)

   # Return the response to API Gateway
   return {
       'statusCode': response.getcode(),
       'body': response.read().decode('utf-8'),
       'headers': {
           'Content-Type': 'application/json'
       }
   }

except Exception as e:
# Handle errors
return {
‘statusCode’: 500,
‘body’: json.dumps({
‘error’: f”Error: {str(e)}”
}),
‘headers’: {
‘Content-Type’: ‘application/json’
}
}

Testing the Solution

You can test the payment gateway service through the API Gateway endpoint:

bash

API Gateway URL

API_URL=”https://xxyyzzxx.execute-api.us-east-1.amazonaws.com/prod”

Process a payment

curl -X POST “$API_URL/api/process-payment” \
-H “Content-Type: application/json” \
-d ‘{
“amount”: 100.00,
“currency”: “USD”,
“gateway”: “paypal”,
“payment_method”: “paypal_balance”,
“metadata”: {
“order_id”: “12345”
}
}’

Future Enhancements

To take this POC to production, there are several enhancements we’re planning to implement:

1. Authentication and Authorization

The current implementation lacks proper authentication and authorization. We plan to enhance this by:

• Implementing OAuth 2.0 or JWT-based authentication for API Gateway endpoints
• Adding fine-grained authorization using AWS IAM roles and policies
• Implementing API keys for rate limiting and client identification
• Setting up AWS WAF to protect against common web exploits

2. Persistent Transaction Storage

Currently, our payment gateway service uses in-memory storage, which is lost when the container restarts. We plan to implement:

• Amazon DynamoDB for transaction storage with the following schema:
  • Partition key: TransactionID
  • Sort key: Timestamp
  • Attributes: Amount, Currency, Gateway, Status, Metadata
• DynamoDB Streams to trigger notifications for transaction status changes
• Amazon S3 for long-term transaction archival and compliance
• Backup and recovery mechanisms for transaction data

3. Real Payment Gateway Integrations

The current implementation uses mock payment gateways. We plan to integrate with real payment providers:

• PayPal API integration with OAuth authentication
• Stripe API integration with webhook support
• Adyen API integration for European markets
• Implementing retry logic and idempotency for payment operations
• Setting up proper error handling for payment gateway failures

4. Enhanced Monitoring and Observability

To ensure the reliability of our payment service, we can plan to implement:

• Amazon CloudWatch dashboards for monitoring key metrics
• CloudWatch Alarms for critical thresholds (error rates, latency)
• AWS X-Ray for distributed tracing across services
• Custom metrics for payment success rates, average transaction values, etc.
• Automated anomaly detection for unusual payment patterns

5. High Availability and Disaster Recovery

To ensure the service remains available even during failures:

• Multi-AZ deployment for ECS services
• Automated failover mechanisms
• Regular backup and restore testing
• Chaos engineering practices to test resilience
• Implementing circuit breakers for external service dependencies

6. Compliance and Security Enhancements

For payment services, compliance is critical:

• PCI DSS compliance implementation
• Encryption of sensitive data at rest and in transit
• Regular security audits and penetration testing
• Implementing AWS Config rules for compliance monitoring
• Setting up AWS CloudTrail for audit logging

These enhancements will transform our POC into a production-ready payment processing service that is secure, reliable, and compliant with industry standards.

Conclusion

AWS VPC Lattice provides an elegant solution for cross-VPC communication, especially for service-oriented architectures. This payment gateway POC demonstrates how VPC Lattice can simplify networking, enhance security, and improve observability for cross-VPC service communication.

By isolating the payment gateway service in its own VPC while making it accessible to clients in other VPCs, we’ve created a more secure and maintainable architecture that can scale as our application grows.

Despite the challenges I faced with ECS service stability and cross-VPC connectivity, the benefits of this architecture make it a compelling approach for building secure, scalable payment processing services.

Have you used VPC Lattice in your projects? What challenges did you face? Let me know in the comments!