The Sidecar Pattern: Scaling Microservices on AWS

How the Sidecar Pattern enhances logging, security, and observability in Amazon EKS

and

Feb 23, 2025

Hello guys, if you are preparing for System Design interview or become a tech lead or Software architect, knowledge of Microservices architecture goes a long way.

Earlier, I have shared Microservices Design Patterns, as well as System design interview guide, and common System design concepts and discussed how to design Twitter and WhatsApp and in this article to discuss about one of the critical pattern called Sidecar.

For this post, I have partnered with

Amrut Patil

, an AWS expert who is going to share his thoughts on Sidecar pattern and how you can use this pattern to scale Microservices on AWS.

The sidecar pattern has emerged as a powerful architectural solution for extending and enhancing microservices without modifying their core functionality.

In Amazon EKS, sidecars are valuable for implementing cross-cutting concerns like logging, security, and observability.

In this newsletter, I’ll explain practical implementations and best practices for leveraging the sidecar pattern in AWS environments.

Let’s get started.

Understanding the Sidecar Pattern

Think of a sidecar as a companion container alongside your main application container within the same pod.

Like a motorcycle sidecar, it complements and extends the capabilities of the primary vehicle without changing its core functionality.

Why Do We Need the Sidecar Pattern?

Modern microservices architectures face several operational challenges that can become overwhelming when handled within the main application.

The sidecar pattern emerged as a response to these challenges, providing an elegant solution to common problems in distributed systems.

Core Problems Solved by the Sidecar Pattern

Separation of Operational Logic
- Problem: Application code becomes bloated with operational concerns like logging, monitoring, and security.
- Solution: Sidecars handle these operational aspects independently, keeping the main application focused on business logic.
Technical Debt in Legacy Applications
- Problem: Legacy applications often lack modern observability and security features.
- Solution: Sidecars can add these capabilities without modifying the legacy codebase, reducing risk and effort.
Standardization Across Different Technologies
- Problem: Different services written in various languages need consistent logging, monitoring, and security implementations.
- Solution: Sidecars provide a standardized approach regardless of the main application's technology stack.
Dynamic Configuration Management
- Problem: Updating configuration across numerous services is complex and error-prone.
- Solution: Configuration sidecars can handle dynamic updates without application restarts.
Complex Security Requirements
- Problem: Implementing SSL/TLS, authentication, and authorization in each service is repetitive and risky.
- Solution: Security sidecars handle these concerns consistently across all services.

Practical Implementation Examples

1. Logging Sidecar Implementation

Here's a practical example of implementing a Fluent Bit sidecar for centralized logging:

apiVersion: apps/v1

kind: Deployment

metadata:

name: application-with-logging

spec:

template:

spec:

containers:

- name: main-application

image: app:latest

volumeMounts:

- name: logs

mountPath: /var/log

- name: logging-sidecar

image: fluent/fluent-bit:latest

volumeMounts:

- name: logs

mountPath: /var/log

- name: fluent-bit-config

mountPath: /fluent-bit/etc/

volumes:

- name: logs

emptyDir: {}

- name: fluent-bit-config

configMap:

name: fluent-bit-config

Configure Fluent Bit to ship logs to CloudWatch:

apiVersion: v1

kind: ConfigMap

metadata:

name: fluent-bit-config

data:

fluent-bit.conf: |

[INPUT]

Name tail

Path /var/log/*.log

Parser docker

[OUTPUT]

Name cloudwatch

Match *

region us-west-2

log_group_name /eks/application-logs

log_stream_prefix application-

2. Security Sidecar with AWS App Mesh

Implement mutual TLS authentication using AWS App Mesh:

apiVersion: appmesh.k8s.aws/v1beta2

kind: VirtualNode

metadata:

name: application-node

spec:

listeners:

- portMapping:

port: 8080

protocol: http

tls:

mode: STRICT

certificate:

acm:

certificateARN: arn:aws:acm:region:account:certificate/certificate-id

serviceDiscovery:

dns:

hostname: application.local

3. Observability with AWS Distro for OpenTelemetry

Deploy the AWS OpenTelemetry collector as a sidecar:

apiVersion: apps/v1

kind: Deployment

metadata:

name: application-with-otel

spec:

template:

spec:

containers:

- name: main-application

image: app:latest

env:

- name: OTEL_EXPORTER_OTLP_ENDPOINT

value: "http://localhost:4317"

- name: otel-collector

image: amazon/aws-otel-collector:latest

command:

- "/awscollector"

args:

- "--config=/conf/collector-config.yaml"

volumeMounts:

- name: collector-config

mountPath: /conf

volumes:

- name: collector-config

configMap:

name: otel-collector-config

Configure the OpenTelemetry collector:

apiVersion: v1

kind: ConfigMap

metadata:

name: otel-collector-config

data:

collector-config.yaml: |

receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

exporters:

awsxray:

region: us-west-2

service:

pipelines:

traces:

receivers: [otlp]

exporters: [awsxray]

Best Practices for Sidecar Implementation

1. Resource Management

Set appropriate resource limits:

resources:

requests:

memory: "64Mi"

cpu: "250m"

limits:

memory: "128Mi"

cpu: "500m"

2. Health Monitoring

Implement health checks for both containers:

livenessProbe:

httpGet:

path: /health

port: 8080

initialDelaySeconds: 15

periodSeconds: 20

3. Lifecycle Management

Configure proper startup and shutdown order:

lifecycle:

postStart:

exec:

command: ["/bin/sh", "-c", "wait-for-service.sh"]

preStop:

exec:

command: ["/bin/sh", "-c", "graceful-shutdown.sh"]

Common Use Cases

Logging and Monitoring
- Log aggregation and forwarding
- Metric collection and export
- Distributed tracing
Security
- TLS termination
- Authentication/Authorization
- Certificate management
- Policy enforcement
Configuration
- Dynamic config updates
- Feature flag management
- Service discovery
Network Control
- Traffic management
- Circuit breaking
- Rate limiting
- A/B testing

Security Considerations

Use IAM roles for service accounts (IRSA)
Implement network policies to control pod-to-pod communication
Regular security scanning of sidecar images
Encrypt all sensitive configuration data

Final Thoughts

The sidecar pattern provides a powerful way to enhance your microservices architecture in EKS.

Following the implementation examples and best practices outlined in this newsletter, you can effectively implement logging, security, and observability while maintaining a clean separation of concerns.

Next Steps

Audit your current microservices architecture
Identify candidates for sidecar implementation
Start with a pilot project using logging sidecars
Gradually expand to security and observability
Measure and optimize performance

Thank you!

A big thank you to

javinpaul

for giving me this guest post opportunity. I hope you enjoyed reading this and learned how the Sidecar Pattern enhances logging, security, and observability in Amazon EKS.

To elevate your AWS Cloud skills further, consider subscribing to my newsletter, The Cloud Playbook.

About the Author

I’m Amrut Patil.

I am an Engineering Leader who empowers businesses and leads teams to build scalable, cost-effective, secure, and resilient cloud, data engineering, devops, and AI solutions using the AWS Cloud.

I have worked in the software industry for 10+ years with experience across the entire software development cycle.

I currently hold the following 5 AWS certifications: