Building a digital badge system with the help of Kiro (and Amazon ECS Express Mode

Source: Dev.to

Getting Started

I develop the app with Kiro. The first thing I needed was a way to prepare the project for deployment to Amazon ECS Express Mode.

1. Add the ECS MCP Server – I usually consult the docs when my memory is hazy, but now I let my AI‑coding tools do the heavy lifting. I added the Amazon ECS MCP Server to my Kiro session:

{
  "mcpServers": {
    "awslabs.ecs-mcp-server": {
      "command": "uvx",
      "args": ["--from", "awslabs-ecs-mcp-server", "ecs-mcp-server"]
    }
  }
}

Application‑Readiness Evaluation

Next, I asked Kiro for a readiness check:

Prompt: “Using the Amazon ECS MCP Server – provide me with a readiness check for deploying this application to Amazon ECS Express Mode.”

After trusting the MCP Server tools, Kiro returned a concise report. The report highlighted three findings that required changes.

Kiro then gave me a context‑specific checklist (IAM policies, service permissions, etc.) and generated a deployment script. While reviewing the script I noticed a potential problem:

The app expects a BASE_URL (e.g., 127.0.0.1:5001 during local development). I won’t know the DNS name until the service is running on ECS Express.

I asked Kiro for guidance:

Prompt: “I don’t know what to configure for BASE_URL because I don’t have a DNS registered yet. Can you help?”

Kiro updated the code and deployment script to handle this dynamically.

Deploying to Amazon ECS Express

I ran the generated script. The resources were provisioned, services started, but the deployment seemed to stall. Checking CloudWatch logs revealed the error:

exec /bin/sh: exec format error

The issue? My Mac builds ARM‑based container images (aarch64). The script defaulted to amd64, causing the format mismatch.

I corrected the architecture in the Dockerfile / build command to aarch64. After the fix, the service launched successfully.

A quick double‑check of the API docs confirmed the change, and the deployment finally worked.

Takeaways

Deploying a containerised app with Amazon ECS Express Mode is now a repeatable process for me, thanks to Kiro’s AI‑assisted workflow. If you’re building similar services, give the Strands Agent and the ECS MCP Server a try – they’ll save you a lot of manual plumbing.

Amazon ECS Express Mode – My Experience

That the MCP server was able to catch this (for now).

Amazon ECS Express Mode uses amd64 instance types for the initial deployment. Kiro has already taken care of business for me, updating my build script to create amd64 images.

Note! After speaking with folks who know more, you CAN use aarch64 instances with Amazon ECS Express Mode. After you have created your service, you can modify the task‑definition file (the key configuration file – task.json – where you define what you need to deploy your container) and change it to support AWS Graviton instance types. Behind the scenes it’s AWS Fargate that is running the show.

The script wasn’t perfect

For example, after the initial successful deployment, the first time I used the script to update the application it generated this error:

An error occurred (InvalidParameterException) when calling the CreateExpressGatewayService operation: 
Unable to Start a service that is still Draining.

Kiro was able to quickly adjust the deployment script (it was trying to create the same service every time rather than using the update‑service method). You can check all the code – I share the repo at the end of this post.

What Did I Learn?

1. Amazon ECS Express Mode gives you opinionated defaults to make it quick to deploy a container workload, but it’s still Amazon ECS.
   • You still have access to everything you would with a traditional set of ECS resources.
   • Post‑deployment tasks such as configuring custom domains and certificates are straightforward – see the advanced customization guide.
   • You can still edit the task‑definition JSON file if you need or want to make changes.
2. Instance‑type defaults – By default, Express Mode uses amd64 rather than aarch64.
   • Since many workloads are moving to AWS Graviton, it’s useful to know you can switch to Graviton instances via the service‑creation API or by updating the cluster after deployment.
3. The Amazon ECS MCP Server is awesome – It provided everything I needed to understand and work with Express Mode, even though the feature was still new.

Conclusion

While Kiro did most of the heavy lifting in generating the code, a developer still needs to:

• Review the output and spot gaps.
• Ask the right questions (via prompts) to get clarity.

Your role remains critical in delivering working code.

My experience with Amazon ECS Express Mode was great – it makes deploying applications to AWS simple and fast. Combined with Kiro and the Amazon ECS MCP Server, I now have a new default approach for building and deploying applications.

Resources

• Code: The full example is in this GitHub repo – digital‑badge‑vending‑demo.
• Demo video: A short video of the process is available here.
• Documentation: Check out the Amazon ECS Express Mode documentation.
• Kiro CLI: Get started for free – download here.
• Kiro CLI workshop: New to Kiro? Follow the Kiro CLI workshop for a comprehensive walkthrough.
• Feedback: If you found this post helpful, please fill out this 30‑second feedback form. I’ll be forever grateful.