DEV Community: Daniel Sim-Xien

Docker-Compose Gettings IAM Error Credentials

Daniel Sim-Xien — Fri, 12 Dec 2025 15:32:15 +0000

Let's say you've successfully written your first docker-compose applications on your EC2 of your choice and voila deployed it! After maybe a few hours you might get errors like this:

Above was a streamlit project state that got deployed with docker-compose, but IAM credentials might happen regardless of your deployment configuration.

So what happened?

To understand this, we need a basic understanding of EC2 Instance Metadata.

EC2 instance metadata is a REST API accessible only from within the EC2 instance at a fixed link-local IP address: http://169.254.169.254/latest/meta-data/. It requires no authentication and provides information in plaintext or JSON format.

You can test this endpoint using:

TOKEN=`curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

So why is our Docker-Compose project failing then?

Put simply, its because usually we isolate the docker-compose projects into its own network bridge, for example:

services:
  api:
    build:
      context: .
      dockerfile: Dockerfile.api
    expose:
      - "8000"
    volumes:
      - ./tools:/app/tools
    environment:
      - PYTHONUNBUFFERED=1
    restart: unless-stopped
    networks:
      - app-network

  streamlit:
    build:
      context: .
      dockerfile: Dockerfile.streamlit
    ports:
      - "8501:8501"
    expose:
      - "8501"
    environment:
      - PYTHONUNBUFFERED=1
    depends_on:
      - api
    restart: unless-stopped
    networks:
      - app-network

networks:
  app-network:
    driver: bridge

When creating networks like above, accessing this metadata becomes challenging when applications run inside Docker containers, due to Docker’s network isolation and default networking configurations.

How do we solve it

The simplest way to grant a container access to EC2 metadata is to use Docker’s host network mode, which makes the container share the host’s network stack.

services:
  api:
    build:
      context: .
      dockerfile: Dockerfile.api
    volumes:
      - ./tools:/app/tools
    environment:
      - PYTHONUNBUFFERED=1
    restart: unless-stopped
    network_mode: host

  streamlit:
    build:
      context: .
      dockerfile: Dockerfile.streamlit
    environment:
      - PYTHONUNBUFFERED=1
      - API_SERVER_URL=http://api:8000
    depends_on:
      - api
    restart: unless-stopped
    network_mode: host

By sharing the network hosts port directly, this eliminates network isolation, allowing the container to directly access 169.254.169.254. Thus, we shouldn't have any issues regarding IAM service role credentials refreshing and EC2 instance metadata.

Deploying MCP Servers on AWS.. Serverlessly

Daniel Sim-Xien — Sun, 25 May 2025 01:05:24 +0000

At this point, you may find many if not an overwhelming amount of options when considering to deploy MCP (Model Context Protocol) servers. You can choose the embedded route where you directly create these servers through the base framework (ie FastMCP for Pythonistas) or relegate the creation to higher order modules (ie FastAgent)

Well today, its not so much on the creation of these servers but rather the deployment. I will zoom out and instead look at the existing architectural options on the deployment of MCP server architectures on AWS.

1. AWS Solutions Library Version

This architecture shows how to securely deploy Model Context Protocol (MCP) servers on AWS using containers. It covers implementing OAuth 2.0 authentication, adding security layers like CDNs and firewalls, managing client sessions and tokens, setting up centralized logging, and ensuring high availability through container orchestration. Following this deployment helps organizations create a really well-thought out end-to-end archtecture.

Would recommend deploying this if you seek secure, scalable MCP server deployment with maximum system reliability but aren't constrained by cost factors. The caveat to this solution is to a non-enterprise account holder, this may seem overengineered, especially when the mcp-server is hosted on Fargate runtimes. The other solutions listed here use AWS Lambda to host their MCP servers.

2. Direct AWS Lambda Deployment using FastMCP

This deployment method is a serverless FastMCP server using Python on AWS Lambda. It uses AWS API Gateway for handling requests and AWS SAM for easy deployment, offering a simple way to host MCP services without managing servers. This deployment method is arguably probably the most popular for deploying mcp servers directly for python developers. It leverages FastMCP base framework so all the FastMCP functionalities are available to you from the get-go.

The major caveat about using FastMCP on Lambda, you are likely to experience major cold start issues when starting your functions, approximately 3-5 seconds. Another caveat is that using python, you would have to deploy the solution with an additional LambdaAdapterLayer which is written in Rust
arn:aws:lambda:us-east-1:753240598075:layer:LambdaAdapterLayerX86:25.

This may be a concern if you care about making your solution as lean as possible.

3. Lambda-MCP-Server

This wonderful gem of a library was made by Mike Chambers, a Developer Advocate at AWS. And its so far the most recent and leanest example on MCP server side implementation I've seen so far. The library takes the entire MCP protocol logic and rewrote it for faster and more efficient usage in lambda.

One key boon on using this library is that the connection itself has been rewritten to be MCP-compliant while removing most of the latency issue that the previous lambda+FastMCP has. The con here is that the library is not maintained by the official FastMCP team, so you may not find long-term or most up-top-date updates on the MCP protocol using this library. Lastly, so far the library has been geared towards tool usage, instead of other things like resource, so keep that in mind.

Hope you've learnt something. Feel free to Connect with me on (linkedin)[https://www.linkedin.com/in/daniel-sim-xien-709445112/].

Crafting Minimal Viable IAM Permissions for Amazon Bedrock

Daniel Sim-Xien — Sun, 11 May 2025 01:51:13 +0000

In many ways, most AWS accounts usually require very specific minimum viable permissions (MVP) assigned to user groups. This is usually controlled through templates like AWS Organizations Landing Zone, where the account governor usually has to manually define the scope of access manually. What if we could generate permissions policies via a prompt?

Minimal Viable IAM Permissions for Amazon Bedrock with Langchain

As Cloud Governance specialist, we now have access to powerful tools like Amazon Bedrock and Langchain. But with great power comes great responsibility, especially when it comes to security. In this post, we'll explore how to create minimal viable IAM (Identity and Access Management) permissions for Amazon Bedrock when using it with Langchain, and we'll include some Python code examples.

Understanding the Stack

Amazon Bedrock: A fully managed service offering high-performing foundation models.
Langchain: A framework for developing applications powered by language models.
IAM: AWS's Identity and Access Management service for controlling access to AWS resources.

The Importance of Minimal Permissions

Implementing the principle of least privilege is crucial when working with AI services. It helps:

Reduce the potential attack surface
Minimize the risk of unintended actions
Comply with security best practices

Key Bedrock Actions for Langchain Integration

When using Langchain with Bedrock, we typically need these main actions:

bedrock:InvokeModel: To call the model
bedrock:ListFoundationModels: To list available models (optional)
bedrock:GetFoundationModel: To get model details (optional)

Sample IAM Policy

Here's a minimal IAM policy for Bedrock use with Langchain:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel"
            ],
            "Resource": "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-v2"
        }
    ]
}

This policy allows invoking the Claude v2 model, which is commonly used with Langchain.

Python Code Example

Let's see how to use this with Langchain:

import boto3
from langchain.llms import Bedrock

# Assume AWS credentials are set up in your environment
bedrock_client = boto3.client(
    service_name='bedrock-runtime',
    region_name='us-west-2'
)

# Initialize the Bedrock LLM
llm = Bedrock(
    model_id="anthropic.claude-v2",
    client=bedrock_client,
    model_kwargs={"max_tokens_to_sample": 256}
)

# Use the LLM
response = llm("Produce a IAM permissions policy with only read and write access to the bucket name <'INSERT BUCKET NAME HERE'> only")
print(response)

This example we're using the boto3 client with Langchain's Bedrock integration. The IAM permissions we set earlier allow this code to run successfully.

Best Practices

Use IAM roles: Attach these permissions to IAM roles rather than individual users.
Regular audits: Periodically review and update your IAM policies.
Environment-specific permissions: Use different permissions for development, testing, and production environments.

Troubleshooting

If you encounter permission issues, check the following:

Ensure the IAM policy is attached correctly to your role or user.
Verify that the region in your code matches the region in the IAM policy.
Check AWS CloudTrail logs for specific permission denied errors.

Conclusion

By implementing minimal viable IAM permissions for Amazon Bedrock when using Langchain, you're taking a crucial step in securing your AI applications. Of course you gotta remember to regularly review and update your permissions as your application's needs evolve.

Happy secure coding!