AWS Developer Tools Every Python Developer Should Know in 2026

The AWS developer tools page lists more than thirty products. At least four of them do something you could easily mistake for the same thing. Several have changed names in the last two years, one stopped accepting new customers in November 2025, and the IDE that many developers built their workflow around is being replaced by something built from scratch. Without a clear picture of what belongs where, picking the wrong starting point costs weeks of work that you do not get back.

This article maps the six categories of AWS developer tools that matter for Python developers in 2026: coding assistance, agentic AI, infrastructure as code, CI/CD pipelines, container management, and secrets management. For each category, you will see which tools to use, which ones to skip, and how they connect in a real production project. The examples come from Kintaraa, a mobile-first AI platform built for communities in Kenya, which runs six containerised services, an AI pipeline, and an offline-capable React frontend on AWS.

Prerequisites

To follow the code examples in this article, you need a few things in place before you start.

• An AWS account with IAM (Identity and Access Management) permissions for ECR, ECS, Systems Manager, and CDK
• Python 3.12 or higher installed locally
• Docker installed and running

• The AWS CLI (Command Line Interface) installed and configured:
  

  $ aws configure
  

• Node.js 18 or higher, which the AWS CDK section requires

How AWS Organises Its Developer Tools

Before diving into any individual tool, it helps to see the full territory in one view. AWS groups its developer tools into six functional categories, and understanding those categories is the fastest way to know which product page to open when you have a specific problem to solve.

Category	Problem it solves	Tools to reach for
Coding and AI assistance	Writing, debugging, and generating code faster	Kiro IDE
Agentic AI	Building AI pipelines and multi-agent applications	Strands Agents SDK, Amazon Bedrock Agents
Infrastructure as Code	Defining and deploying cloud resources repeatably	AWS CDK, CloudFormation
CI/CD pipelines	Automating build, test, and deploy on every commit	CodeBuild, CodePipeline, CodeDeploy
Container management	Storing and running Docker images at scale	Amazon ECR, Amazon ECS Fargate
Secrets and configuration	Keeping API keys and credentials out of your codebase	SSM Parameter Store, Secrets Manager

Two tools are notably absent from that table. Amazon CodeCatalyst stopped accepting new customers in November 2025. Amazon Q Developer IDE plugins stopped accepting new signups in May 2026 and reach end of support in April 2027. A developer starting a project today should not build on either of them. Everything in the table above is active, maintained, and worth learning.

Kintaraa uses tools from every row in that table. The sections that follow walk through each category with the specific context that the docs page does not give you.

Coding Assistance with Kiro

Kiro is the AWS agentic IDE (Integrated Development Environment), built on Visual Studio Code's open-source foundation, and it represents a different approach to how developers work with AI during a project.

Most AI coding tools respond to what you type in the moment. You write a comment, the tool suggests a completion. You ask a question, it answers. Kiro works from a specification instead. You describe what you want to build in structured natural language, the spec, and Kiro treats that spec as the source of truth. The code it generates, verifies, and maintains is a build artifact of that spec, not the other way around.

This changes the unit of work from the prompt to the requirement. Instead of nudging an AI toward one function at a time, you describe a feature and Kiro plans, implements, and tests it across your codebase.

What Makes Kiro Different from Other AI Coding Tools

Kiro is built on Code OSS, which means your existing VS Code themes, keybindings, and Open VSX extensions work without changes. Under the hood, Kiro routes between Claude Sonnet for reasoning-heavy spec interpretation and Amazon Nova for high-throughput code generation, using Amazon Bedrock as the unified model layer.

It ships in three forms: Kiro IDE is the VS Code-compatible editor for day-to-day development, Kiro CLI brings the same agent to your terminal for SSH sessions and scripted workflows, and Kiro Autonomous Agent runs in the background, picks up tasks, implements them, and opens pull requests without you in the loop.

A Kiro spec for a session management API looks like this:

name: session-api
description: Anonymous session management for the Kintaraa backend
requirements:
  - Generate a UUID session token on POST /api/session
  - Store the token in Redis with a 24-hour TTL
  - Return 401 on any request with an expired or missing token
  - Never log or store any user-identifiable information alongside the token

From that spec, Kiro generates the FastAPI router, the Pydantic models, and the test cases. When the session format changes, updating the spec propagates the change through the implementation. The spec becomes the document you review in a pull request, not the code diff.

Kiro Hooks

Hooks are the feature that makes Kiro composable with your existing workflow. A Hook is a trigger that fires on a specific event, such as a file save, a commit, or a pull request, and runs an automated agent action in response. You configure what runs, Kiro runs it.

In practice this means your documentation can update automatically when a source file changes, your test fixtures can regenerate when a schema changes, and your linter can run on every save without a manual command. The agent handles it based on the event, not because you remembered to run it.

[!NOTE]
Kiro is available at kiro.dev. New Amazon Q Developer IDE plugin signups closed on May 15, 2026. Existing subscribers keep access until April 30, 2027, when the IDE plugins reach end of support.

Building AI Agents with AWS Strands

When your application needs to do more than call a language model and return a response, when it needs to use tools, reason across multiple steps, or coordinate several specialised components, you need an agent framework. AWS Strands Agents is the open-source answer to that problem.

What Strands Agents Does

Strands Agents is an open-source Python and TypeScript SDK that AWS released in May 2025. It treats the language model as the reasoning engine. You define Python functions as typed tools, decorate them with @tool, hand them to an Agent, and the model decides when and how to call them based on the user's request. There is no fixed sequence of steps. The model reasons about the tool to call, calls it, reads the result, and decides what to do next.

The SDK reached 14 million downloads in its first year. AWS teams use it internally across Amazon Q Developer, AWS Glue, and VPC Reachability Analyzer.

A Strands Agent in Practice

The example below shows a minimal working agent that helps a user find local services. It uses one tool. A production agent would have several.

from strands import Agent
from strands.tools import tool


@tool
def find_services(category: str, county: str) -> list[dict]:
    """Find support services by category and county.

    Args:
        category: The type of service, for example legal or health.
        county: The county to search within.

    Returns:
        A list of matching service records.
    """
    # Query your database here
    ...


agent = Agent(
    model="us.anthropic.claude-sonnet-4-5",
    tools=[find_services],
    system_prompt="You help users locate support services in their area.",
)

response = agent("Find legal services in Nairobi County.")
print(response)

The model receives the user's request, reasons that find_services is the right tool to call, passes category="legal" and county="Nairobi County" as arguments, reads the result, and incorporates it into a response. You write no orchestration code. The model handles the routing.

Kintaraa uses LangGraph for its AI pipeline and exposes tools through FastMCP servers. Strands and LangGraph solve the same problem from different directions. LangGraph gives you explicit, auditable control over the graph of agent states, which matters when each transition in the pipeline needs to be traceable. Strands delegates routing decisions to the model, which reduces orchestration code and suits teams that want faster iteration on tool design. Both are valid choices; the decision comes down to how much control your use case requires.

[!NOTE]
Strands Agents supports Claude models via the Anthropic API, any model available in Amazon Bedrock, Llama via Llama API, and other providers through LiteLLM. For local development, it works with Ollama.

Infrastructure as Code with AWS CDK

Infrastructure as code means defining your cloud resources in files that live in version control alongside your application code, so every load balancer, database, and container is reproducible, reviewable, and deployable with a single command.

CDK, CloudFormation, and Terraform

Three tools dominate the IaC conversation on AWS. Understanding what separates them saves you from switching halfway through a project.

Factor	AWS CDK	CloudFormation	Terraform
Language	Python, TypeScript, Java, Go, C#	JSON or YAML	HCL
State management	AWS manages it via CloudFormation	AWS manages it	You manage it
Multi-cloud support	AWS only	AWS only	Yes
Deploy time for 20 resources	3 to 5 minutes	3 to 5 minutes	1 to 3 minutes
Best for	Python teams on AWS	Existing CloudFormation stacks	Multi-cloud or platform engineering teams

If you are a Python developer on an AWS-only project, CDK is the right choice. You write typed Python classes that CDK compiles into CloudFormation templates. AWS manages the state. You do not learn a separate language or manage a state file.

Terraform wins when your infrastructure spans multiple cloud providers or when your organisation already has a Terraform platform team with a shared state backend. One option is no longer available: CDK for Terraform was deprecated by HashiCorp in 2025, so there is no hybrid path between the two tools.

Deploying a Containerised Service with CDK

The stack below defines an ECS (Elastic Container Service) Fargate service that pulls an image from ECR (Elastic Container Registry) and exposes it behind an Application Load Balancer.

from aws_cdk import Stack, aws_ecs as ecs, aws_ecs_patterns as ecs_patterns, aws_ecr as ecr
from constructs import Construct


class AppStack(Stack):
    """Defines an ECS Fargate service pulling an image from ECR.

    Args:
        scope: The CDK construct scope.
        construct_id: A unique identifier for this stack.
    """

    def __init__(self, scope: Construct, construct_id: str, **kwargs: object) -> None:
        super().__init__(scope, construct_id, **kwargs)

        repo = ecr.Repository.from_repository_name(self, "AppRepo", "my-app-backend")
        cluster = ecs.Cluster(self, "AppCluster")

        ecs_patterns.ApplicationLoadBalancedFargateService(
            self,
            "AppService",
            cluster=cluster,
            cpu=512,
            memory_limit_mib=1024,
            task_image_options=ecs_patterns.ApplicationLoadBalancedTaskImageOptions(
                image=ecs.ContainerImage.from_ecr_repository(repo, tag="latest"),
                container_port=8000,
            ),
            desired_count=2,
            public_load_balancer=True,
        )

Synthesise and deploy it with two commands:

$ cdk synth
$ cdk deploy

cdk synth compiles the Python into a CloudFormation template and prints it to your terminal so you can inspect every resource before anything changes. That review step is not optional for production work.

Kintaraa runs six services on ECS Fargate. The CDK stack defines each service, its memory allocation, and its connection to ECR in typed Python. Adding a new service means copying an existing pattern and adjusting two or three values, not learning a new CloudFormation resource type.

CI/CD with CodeBuild and CodePipeline

A CI/CD (Continuous Integration and Continuous Delivery) pipeline runs your tests, checks your code quality, builds your Docker image, and deploys it automatically every time you push to your main branch. Three AWS services handle the different stages of that process.

What Each Service Does

CodeBuild is the compute environment that executes your commands. It reads a buildspec.yml file from your repository and runs the phases you define in it. CodePipeline is the orchestrator. It watches your source repository for changes, triggers CodeBuild, and coordinates the stages of the pipeline in sequence. CodeDeploy handles the final delivery to your compute target, whether that is an EC2 instance, a Lambda function, or an ECS service.

A buildspec.yml for a Python Application

The file below runs a full quality gate before building a Docker image: lint with ruff, type-check with mypy, test with pytest, then build and push to ECR only if all three pass.

version: 0.2

phases:
  install:
    runtime-versions:
      python: "3.12"
    commands:
      - pip install uv --break-system-packages
      - uv sync --frozen

  pre_build:
    commands:
      - uv run ruff check .
      - uv run mypy app/
      - uv run pytest tests/ -v
      - aws ecr get-login-password --region $AWS_REGION
          | docker login --username AWS
            --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

  build:
    commands:
      - docker build -t $IMAGE_URI .
      - docker tag $IMAGE_URI $ECR_REPO_URI:latest
      - docker tag $IMAGE_URI $ECR_REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION

  post_build:
    commands:
      - docker push $ECR_REPO_URI:latest
      - docker push $ECR_REPO_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION

[!WARNING]
Do not hardcode AWS account IDs or region names in your buildspec.yml. Pass them as environment variables through CodeBuild so the same file works across accounts and regions without modification.

Kintaraa's pipeline runs ruff, mypy, and pytest before it builds a single Docker layer. A linting failure or a type error stops the pipeline before it touches ECR. The image that reaches production passed every check.

Containers and Secrets

Two habits separate a production-ready AWS deployment from one that will cause problems. The first is storing Docker images in a managed registry rather than Docker Hub. The second is storing secrets in a managed secrets service rather than environment files checked into version control.

Amazon ECR

Amazon ECR is a fully managed Docker image registry. It is private by default, integrates directly with ECS and CodeBuild through IAM, and scans images for known CVEs (Common Vulnerabilities and Exposures) using Amazon Inspector.

Push your first image with five commands:

1. Create the repository:
   

   $ aws ecr create-repository --repository-name my-app --region af-south-1
   

2. Authenticate Docker:
   

   $ aws ecr get-login-password --region af-south-1 \
       | docker login --username AWS \
         --password-stdin <account-id>.dkr.ecr.af-south-1.amazonaws.com
   

3. Build, tag, and push:
   

   $ docker build -t my-app .
   $ docker tag my-app:latest <account-id>.dkr.ecr.af-south-1.amazonaws.com/my-app:latest
   $ docker push <account-id>.dkr.ecr.af-south-1.amazonaws.com/my-app:latest
   

Enable scan-on-push so every new image receives an automatic vulnerability report:

$ aws ecr put-image-scanning-configuration \
    --repository-name my-app \
    --image-scanning-configuration scanOnPush=true \
    --region af-south-1

Treat a CRITICAL severity finding as a deployment blocker. Your pipeline can query scan results and fail the build before the image reaches ECS:

$ aws ecr describe-image-scan-findings \
    --repository-name my-app \
    --image-id imageTag=latest \
    --region af-south-1 \
    --query "imageScanFindings.findingSeverityCounts"

Kintaraa stores all six service images in ECR with scan-on-push enabled. No image reaches the ECS cluster without passing both the quality gate in CodeBuild and the vulnerability scan in ECR.

AWS Systems Manager Parameter Store

A .env file that contains your production API keys is a deployment that is one accidental commit away from a serious incident. SSM (AWS Systems Manager) Parameter Store removes that risk by storing secrets as named, encrypted parameters that your application retrieves at runtime.

Your ECS task role grants permission to call ssm:GetParametersByPath. The container reads its configuration at startup, and no secret ever appears in the image, the repository, or the build logs.

The function below reads from Parameter Store and populates the same pydantic-settings model that your local .env file feeds in development. The application code does not change between environments. Only the source of the values changes.

import boto3
from app.config import Settings


def load_from_ssm(env: str = "prod") -> Settings:
    """Load application settings from SSM Parameter Store.

    Args:
        env: The environment prefix used in parameter names.

    Returns:
        A populated Settings instance.
    """
    client = boto3.client("ssm", region_name="af-south-1")
    prefix = f"/my-app/{env}/"

    response = client.get_parameters_by_path(
        Path=prefix,
        WithDecryption=True,
    )

    params = {
        p["Name"].replace(prefix, ""): p["Value"]
        for p in response["Parameters"]
    }

    return Settings(**params)

Store a secret with the CLI:

$ aws ssm put-parameter \
    --name "/my-app/prod/ANTHROPIC_API_KEY" \
    --value "sk-ant-..." \
    --type SecureString \
    --key-id alias/aws/ssm \
    --region af-south-1

[!NOTE]
The af-south-1 AWS region in Cape Town gives the lowest latency for applications serving users across East and Southern Africa. Choose the region closest to your primary users.

How to Choose the Right Tool

The tools in this article do not compete. Each one owns a specific job in your development workflow. The table below maps the job to the tool so you can make the decision without reading every product page.

If you need to...	Use this
Write code and generate features with AI assistance	Kiro IDE
Build an AI agent that reasons across tools and multiple steps	Strands Agents SDK
Define AWS infrastructure in Python	AWS CDK
Automate your build, test, and deploy pipeline	CodeBuild and CodePipeline
Store and version Docker images with vulnerability scanning	Amazon ECR
Keep API keys and secrets out of your codebase	SSM Parameter Store
Store secrets with automatic rotation on a schedule	AWS Secrets Manager
Cache Python packages privately and speed up CI builds	CodeArtifact

If you are setting up AWS developer tooling for the first time, start here. Install Kiro and use it for your development environment. Set up ECR for your Docker images and Parameter Store for your secrets. When you have a working application, add CodeBuild and CodePipeline to automate testing and deployment. Add CDK when your infrastructure grows complex enough that you want to define it in Python alongside your application code. That order matters because each step builds on the previous one.

Two tools that do not appear in the decision table are worth naming once so you know to avoid them. CodeCatalyst stopped accepting new customers in November 2025. Amazon Q Developer IDE plugins stop working in April 2027. Do not start new projects on either.

Frequently Asked Questions

What are the AWS developer tools?

AWS developer tools are a set of managed services that support the full software development lifecycle on AWS. They cover coding assistance with Kiro IDE, agentic AI with Strands Agents, infrastructure as code with AWS CDK and CloudFormation, continuous integration and delivery with CodeBuild and CodePipeline, container image management with Amazon ECR, and secrets management with SSM Parameter Store and Secrets Manager.

What is the difference between AWS CDK and CloudFormation?

AWS CDK is a framework that lets you define cloud infrastructure using Python, TypeScript, or other general-purpose programming languages. CloudFormation is the underlying AWS service that CDK compiles to. It reads JSON or YAML templates and provisions the resources described in them. Most developers who write Python should use CDK directly. Raw CloudFormation templates remain relevant when migrating existing stacks or integrating with tools that generate them directly.

What replaced Amazon Q Developer?

Kiro replaced Amazon Q Developer as the primary AWS agentic coding environment. Amazon Q Developer IDE plugin signups closed on May 15, 2026, and the plugins reach end of support on April 30, 2027. Kiro is available at kiro.dev and works as a VS Code-compatible IDE, a CLI tool, and an autonomous agent that opens pull requests without manual intervention.

What is AWS Strands Agents?

AWS Strands Agents is an open-source Python and TypeScript SDK for building AI agents, released by AWS in May 2025. You define Python functions as typed tools, decorate them with @tool, and pass them to an Agent that uses a language model to decide when and how to call them. It supports Claude, Amazon Bedrock models, Llama, Ollama, and other providers via LiteLLM, and reached 14 million downloads in its first year.

What is the difference between SSM Parameter Store and Secrets Manager?

Both services store secrets securely, but they serve different purposes. Parameter Store is a general configuration store for API keys, database connection strings, feature flags, and any value your application reads at startup. Secrets Manager adds automatic credential rotation on a configurable schedule and is designed for database passwords and third-party API keys that need to rotate regularly. Parameter Store has a free tier for standard parameters. Secrets Manager does not.

Conclusion

The AWS developer toolchain covers every stage of building and running a production Python application. Kiro handles code generation from structured specs. Strands Agents powers multi-step AI pipelines. CDK defines your infrastructure in typed Python. CodeBuild and CodePipeline automate your quality gates and deployments. ECR stores and scans your container images. Parameter Store keeps your secrets out of your repository.

None of these tools are optional at scale, and none of them require you to adopt all of them at once. Start with the two or three that solve your most immediate problem and add the rest as your application grows.

The next article in this series walks through setting up Kiro IDE from installation to your first spec-driven feature, with step-by-step instructions and real configuration examples.

Learn more on the AWS Developer Tools product page