DEV Community: Aleksandra Ljuboje

Practical ECS Configurations in Terraform that make your Life easier

Aleksandra Ljuboje — Wed, 28 Jan 2026 08:59:53 +0000

Getting started with ECS as a DevOps engineer is a learning journey in itself - a bit like assembling a complex puzzle—every tiny piece needs to click into place for it to run smoothly.

Implementing it in Terraform as Infrastructure as Code adds another layer to the story.

Here are a few key considerations that can save your production deployments and help make your solution more robust and reliable

Propagating Tags Automatically (and Correctly)

Tagging is essential for cost allocation, ownership, and governance, but some ECS resources don’t automatically inherit tags unless you explicitly configure them.

Why is that? When writing Infrastructure as Code, you typically define the Task Definition and the Service. The actual Tasks that run are deployed based on those definitions and inherit most of their configuration from them, but not tags. They appear in your account only when the infrastructure is deployed, which means you need a way to ensure consistent tagging across these ephemeral resources..

To propagate tags correctly in your ECS Service Terraform code, add these two lines:

enable_ecs_managed_tags = true
propagate_tags          = "SERVICE"

Why this matters

Ensures tasks inherit tags from the ECS service – no more untagged tasks floating around.
Makes cost allocation and resource ownership clear – essential for reporting and chargebacks.
Reduces the risk of “untagged” resources appearing in billing or compliance reports.

This is especially important in larger organizations where tagging policies are enforced.

Reference: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html

Preventing ECS from Lowering Desired Count in Production

In production environments, Terraform shouldn’t override operational realities like autoscaling adjustments or manual scaling during incidents. Without proper handling, a terraform apply could unintentionally scale down your ECS service, causing downtime or degraded performance.

You can prevent this by telling Terraform to ignore changes to the desired_count in your ECS Service resource:

lifecycle {
  ignore_changes = [desired_count]
}

Why this matters

Prevents Terraform from scaling your service down unintentionally
Avoids surprises during terraform apply
Works nicely with Application Auto Scaling or manual scaling during incidents

Always Create a Custom CloudWatch Log Group

ECS can automatically create CloudWatch log groups for your tasks, but doing so limits your control over important settings like log retention, naming conventions, and cost management. Defining log groups explicitly in Terraform is a best practice that ensures consistency and predictability.

resource "aws_cloudwatch_log_group" "<project_name>_ecs_log_group" {
  name = "/ecs/<log group name>"
  retention_in_days = 1 # current minimum 
}

Why this matters

Controls log retention and avoids infinite log storage
Helps with cost optimization
Makes log group naming consistent and predictable

Enable ECS Exec for easier Debugging

ECS Exec is a powerful feature that lets you connect directly into a running container from the AWS Console or CLI — no SSH or bastion host required. This is incredibly useful for troubleshooting production issues safely and quickly.

To enable ECS Exec in your service:

enable_execute_command = true

You also need the proper IAM permissions:

resource "aws_iam_policy" "<policy name>" {
  name        = <policy name>
  description = "Give SSM permissions to use ECS exec"

  policy = jsonencode({
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Effect" : "Allow",
        "Action" : [
          "ssmmessages:CreateControlChannel",
          "ssmmessages:CreateDataChannel",
          "ssmmessages:OpenControlChannel",
          "ssmmessages:OpenDataChannel"
        ],
        "Resource" : "*"
      }
    ]
  })
}

How it works

To troubleshoot inside the container click on the running task and scroll until Containers section.

Choose the application container and on the upper left choose the Connect as show in the image below

After this, the terminal in Console will open up, and suggest to paste the command like shown in the example below:

$ aws ecs execute-command --cluster <cluster_name>
--task <placeholder>
--container <container_name> 
--interactive --command '/bin/sh'

To check the healthCheck configuration navigate to:

Task Definitions → choose your Task Definition → Choose a revision → Scroll down to Containers section → Monitoring and logging

Reference: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html

Why this matters

Secure access without opening SSH
Extremely helpful for production debugging

Once you use ECS Exec, it’s hard to go back.

Allow ECS to Temporarily Exceed the Task Limit During Deployments

By default, ECS can be very conservative during deployments. You can speed up rollouts by allowing temporary overprovisioning.

deployment_maximum_percent         = x
deployment_minimum_healthy_percent = y

How ECS Deployment Percentages Work

When ECS deploys a new version of your service, it doesn’t replace all tasks at once. Instead, it gradually shifts traffic from the old tasks to the new ones to avoid downtime. Two key settings control this behaviour deployment_maximum_percent and
deployment_minimum_healthy_percent.

deployment_maximum_percent

This defines the maximum number of tasks ECS can run during a deployment, expressed as a percentage of the desired task count.

Example: if your service normally runs 4 tasks and deployment_maximum_percent = 200, ECS can temporarily run up to 8 tasks during the rollout.

This means, ECS can start new tasks before stopping old ones, ensuring that your service remains available and deployment is faster.

deployment_minimum_healthy_percent

This defines the minimum number of tasks that must remain healthy during the deployment, also as a percentage of the desired task count.

Example: with 4 desired tasks and deployment_minimum_healthy_percent = 50, ECS ensures at least 2 tasks stay healthy at any time.

This means, even if new tasks fail to start or are unhealthy, ECS keeps enough old tasks running so your application continues serving traffic.

Why this matters

Enables zero-downtime deployments
Allows ECS to start new tasks before stopping old ones

This is especially important for production workloads.

Add Container-Level Health Checks

ECS health checks go beyond simply verifying that a container is running — they allow the scheduler to understand whether your application is actually healthy and ready to serve traffic.

By configuring a health check in your task definition, ECS can automatically replace unhealthy containers, improving reliability and reducing downtime.

healthCheck = {
  command     = ["CMD-SHELL", "curl -f http://localhost/status || exit 1"]
  interval    = 10
  timeout     = 5
  retries     = 3
  startPeriod = 10
}

How it works

command – what ECS runs to check the container’s health. Here, it calls a local endpoint /status. If the command fails, the container is marked unhealthy.
interval – how often the health check runs (seconds).
timeout – how long to wait for a response before considering the check failed (seconds).
retries – number of consecutive failures before marking the container unhealthy.
startPeriod – initial grace period for a container to start before health checks begin (seconds).

Why this matters

ECS can automatically replace unhealthy containers
Improves reliability and resilience
Makes deployments safer by detecting bad releases early

Always implement application-level health checks rather than just process-level checks. A container might be running but the app inside could still be failing—health checks catch this early.

And final

Individually, these configurations may seem minor—but together they make a big difference:

Improve operational stability
Reduce deployment risk
Increase observability and debugging ability
Align ECS services with production best practices

If you’re using ECS with Terraform and don’t have these yet, I highly recommend adding them to your baseline.

Let's build great things together! 🚀

AWS Data Transfer Hub

Aleksandra Ljuboje — Mon, 03 Feb 2025 10:40:52 +0000

When you're tasked with migrating a huge number of buckets with metadata included, your heart might skip a beat. That happened to me.
Fortunately, AWS offers a less-known but incredibly useful service—Data Transfer Hub (DTH) — which turned out to be a lifesaver.

The Challenge

The task was to migrate files along with their metadata from a different cloud provider to AWS. Luckily, DTH supported this provider, making the migration process significantly easier in the end.

Deploying Data Transfer Hub

Deploying DTH is straightforward. You simply need to deploy the stack in your preferred AWS region and configure basic settings such as email and credentials. Once that’s done, the rest of the process is smooth sailing.

DTH deploys several AWS services to support its operations, including:

Lambda Functions (to manage automation and processing)
Amazon CloudFront (for content delivery)
Amazon S3 Buckets
Amazon Cognito (for authentication)
AWS AppSync (for managing APIs)
Amazon DynamoDB (for metadata storage)
Amazon ECS
IAM Roles
VPC and ACLs (for network security)
AWS Step Functions (for orchestrating workflows)
Amazon SNS (for notifications and alerts)

This extensive list highlights the complexity of the underlying infrastructure that makes DTH such a powerful tool.

When Stack is succesfully deployed, go to Resources and click on the link provided, it will open up the UI for Sign In, as shown in the image below. Sign in with the temporary credentials set in one of previous steps.

When you are in, choose a Start new transfer task

Choose the S3 since, we are migrating the folders and files in this case :)

You can track the status of task in the new portal.

The logs and graphs are also available, if needed.

When task has been finished, or face some issues, SNS notification will be received. An example is below:

More informations and deployment steps can be found here:
https://github.com/aws-solutions/data-transfer-hub
https://aws.amazon.com/solutions/implementations/data-transfer-hub/

Configuring Data Transfers

When transferring files, beside selecting the source and destination buckets, DTH allows you to configure additional parameters for a tailored migration experience.

When transferring files from other cloud storage providers to Amazon S3, you have multiple options:

Batch File Migration: You can create a list of folders and upload it as a .txt file to a dedicated S3 bucket. DTH will use this list to migrate only the specified folders to S3.
Prefix-Based Transfer: This option enables migrating individual folders while preserving their structure by specifying a prefix. This can be used in cases when huge folder is being migrated or when only one is needed to be migrated.

Challenges Faced During Migration

While the migration process was generally smooth, I encountered some difficulties. One major issue was handling a 4TB bucket—it wasn’t possible to transfer everything at once. Instead, I had to transfer the data in blocks of folders.

The reason for this limitation appears to be related to DTH's internal processing. Although there was available memory, certain folders were not transferred successfully. My suspicion is that this is due to Finder Memory limitations, but further investigation is needed.

Informations that may be useful when choosing Finder Memory

The table below presents data collected from my tests, which may help you select the appropriate Finder Memory. However, I recommend gaining a deeper understanding of performance-related factors to optimize task performance effectively.

Finder Memory	Task Duration	Transfer Size
32GB	40 min	510GB
32GB	15 min	130GB
64GB	40 min	600+GB
16GB	5 min	1.4GB
64GB	20 min	330+GB

What if I need to move additional data later? How to avoid duplicating files?

For that purpose, please choose option to compare data before transfer to avoid duplicates:

It will require more time, but is helpful in those situations.

Conclusion

AWS Data Transfer Hub is an excellent tool for large-scale migrations, offering flexibility and automation to ease the process. While it comes with some limitations, careful planning and testing can help overcome potential challenges. If you find yourself facing a daunting migration task, DTH might just be the hidden gem you need.

Handling API Gateway's "Missing Authentication Token" Error (404) Correctly

Aleksandra Ljuboje — Mon, 03 Feb 2025 09:15:08 +0000

If you've ever worked with AWS API Gateway, you might have encountered the dreaded "Missing Authentication Token" message.
This typically happens when a user tries to access an endpoint without a valid authentication token. However, what confuses many of us is that this error can also appear even when the correct token is provided but the requested resource or path does not exist.

In this blog post, I'll explain why this happens and how you can modify the response to make it more user-friendly by returning a custom 404 error instead of the default 404 "Missing Authentication Token". While there are other potential causes for this error, we were have confirmed that the token was sent correctly and wanted to focus on improving the response message for missing resources.

Why Does "Missing Authentication Token" Appear Even with a Token?

AWS API Gateway throws the "Missing Authentication Token" error when:

The request is sent to an incorrect or non-existent resource path.
The method (GET, POST, etc.) does not exist for the requested resource.
The API Gateway has authentication enabled but the request does not meet the authentication criteria

By default, when a user accesses a non-existent path, API Gateway responds with a 404 "Missing Authentication Token" error instead of a more intuitive 404 "Not Found". This can mislead users into thinking it's an authentication issue when in reality, they are hitting an invalid path, as it was in my case.

How to Change the "Missing Authentication Token" Response

You can customize this response in API Gateway Gateway Responses by following these steps:

Open your API Gateway in the AWS Console.
Navigate to Gateway Responses.
Find and select "Missing Authentication Token".
Change the status code to 404 if it was not already set.
In the Response Template modify the Template Body to return a more meaningful message, such as:

{
  "error": "Not Found",
  "message": "Wrong or non-existent path entered."
}

Keep the Content type as application/json.

The example is shown in the image below.

Now, lets test it with Postman!

I have refined the message a bit :)

Automating the Change Using a YAML Template

If you want to apply this change programmatically, you can use a CloudFormation or OpenAPI definition file. Below is an example test.yml file you can use to modify the Missing Authentication Token response:

openapi: "3.0.1"
info:
  title: "Test API"
  version: "1.0"
paths: {}
x-amazon-apigateway-gateway-responses:
  MISSING_AUTHENTICATION_TOKEN:
    statusCode: 404
    responseTemplates:
      application/json: |
        {
          "error": "Not Found",
          "message": "Wrong or non-existent path entered."
        }

Steps to Deploy the Template

Import the test.yml file inside the API Gateway console.
Deploy the API.
If testing manually, set the method implementation to Mock and then deploy.

If you're using a CloudFormation template.yml, you can apply a similar approach by modifying the GatewayResponse resource for MISSING_AUTHENTICATION_TOKEN.

Changing the Missing Authentication Token message to return a custom 404 error instead of default one makes debugging easier for developers and improves the API's usability.

Have you encountered this issue before? Let me know how you handled it in the comments!

Elevate your emails with Amazon SES Templates -Tips & Tricks

Aleksandra Ljuboje — Fri, 29 Dec 2023 12:15:18 +0000

Have you heard of Amazon Simple Email Service (SES)? In case the answer is "No", in the next lines I will introduce the AWS SES and all the charm it brings to process of sending emails.

Credits for the design - Anna Magura

What is AWS SES?

Amazon Simple Email Service (SES) is an email platform that provides an easy, cost-effective way for you to send and receive email using your own email addresses and domains.

It allows you to send marketing emails such as special offers, transactional emails such as order confirmations, and other types of correspondence such as newsletters. When you use AWS SES to receive mail, you can develop software solutions such as email autoresponders, email unsubscribe systems, and applications that generate customer support tickets from incoming emails.

For more information refer to the documentation.

But …

The feature of AWS SES that will elevate your emails is actually the - TEMPLATES.

Templates allows you to create designs that will be re-usable and save a lot of time!

Here are tips and tricks that will not only enhance your email experience but also add a touch of fun to it!

Note: In this article, we will delve into AWS Lambda and the Python language, which I predominantly use. However, feel free to adapt and re-implement the concepts using your preferred programming language if necessary.

Tip & Trick #1: Enhance the visual appeal of your emails by incorporating HTML, CSS, and static JavaScript for a more polished and engaging presentation

If your emails looks like this:

it is time to change it! Let's elevate your communication to a whole new level.

Credits for the design- Anna Magura

To do so, play with HTML, CSS and static Java Script to create the look you prefer.
After you let your imagination works, here is the coding part:

Create AWS Lambda function
Use Python language to write the code that will send the email on your behalf.

The trick is to create separate Python file where you will put your html code.

Let's call it email_template.py and inside the file create variable called content using the following form:

content = """
<!DOCTYPE HTML PUBLIC ....
< here goes your html, css, js code>
"""

in the main.py which is your main file that contains lambda handler function import the file like shown bellow:

from email_template import content

To send the email I prefer using MIMEApplication, MIMEMultipart and MIMEText and send_raw_email options, because it allows me to manipulate the data and even send the attachment.

Create function that will send the email using MIME and SES client

To create SES Client, we will need commonly used Python boto3 library

ses_client = boto3.client('ses')

One of the methods from MIME is message.attach() that I use to add email body, attachments, etc. where message is variable created using MIMEMultipart('mixed').
To send the email use ses_client.send_raw_email(), like in the example from the documentation:

response = client.send_raw_email(
    Destinations=[
    ],
    FromArn='',
    RawMessage={
        'Data': 'From: sender@example.com\nTo: recipient@example.com\nSubject: Test email (contains an attachment)\nMIME-Version: 1.0\nContent-type: Multipart/Mixed; boundary="NextPart"\n\n--NextPart\nContent-Type: text/plain\n\nThis is the message body.\n\n--NextPart\nContent-Type: text/plain;\nContent-Disposition: attachment; filename="attachment.txt"\n\nThis is the text in the attachment.\n\n--NextPart--',
    },
    ReturnPathArn='',
    Source='',
    SourceArn='',
)

print(response)

As a final touch, as RawMessage we can use previously created message variable and pass it as a string.

Tip & Trick #2: SEMPLATES

The trick is to simply use Semplates!

About Semplates - unlock the full potential of Amazon SES with Semplates' email template service. Design and publish personalized, responsive and branded emails with a few clicks.

In other words, Semplates is a game changer when it comes to AWS SES Templates!

Even if you are not that familiar with Front-End, by using user friendly Interface, you will be able to drag and drop HTML elements to create Template of your choice or even choose one from the provided examples.

After you are done, simply connect your AWS Account with the Semplates account following the well explained steps and Publish the Template.
It will show up in your AWS Account -> SES Templates and you can use it in your Lambda function using the following line of code:

template = ses_client.get_template(TemplateName=<your template name>)

and if needed, extract the HTML code from the template.

For more information, follow the documentation.

Now, let's highlight a few key considerations

Avoid incorporating Dynamic JavaScript content as it lacks support from major email providers like GMAIL.
When utilizing Semplates, ensure to select the correct Region corresponding to your Lambda function.
It's crucial to note when using Semplates as team, that only one user is permitted per Region in AWS Account. This restriction is attributed to security measures, preventing unauthorized individuals from republishing or deleting your created Templates, as clarified by Semplate Support.

In a nutshell, AWS SES adds a touch of fun to email communication! Elevate your messages with engaging designs using HTML, CSS, and static JavaScript. Dive into the world of AWS Lambda and Python for seamless email customization. And for an extra dose of joy, discover the game-changing Semplates - creating personalized, responsive templates has never been this enjoyable! Just remember to pick the right AWS region and embrace the fun side of AWS SES.

Refference:

If you prefer Medium, here is link to the blog post.

Managing AWS Simple Email Service Templates a More Convenient Way - Using Semplates

Using templates to send personalized email with the Amazon SES API

Cross account access to Redshift Serverless via Lambda function

Aleksandra Ljuboje — Tue, 26 Dec 2023 13:13:30 +0000

If you ever tried to connect your AWS Lambda function to Redshift Serverless you know how much effort it took. Well, then you can relate, knowing, how painfull it is to connect it Cross account.

Here are the neccessary steps that will allow your Lambda function to connect and also run queries on Redshift Serverless databases and catalogs.

The Use case that we want to manage is presented on the image bellow:

• Account A wants to connect to Redshift Serverless

• Account B is the account with Redshift Serverless and also cross account that includes the IAM role that the Lambda function assumes

Unlike Redshift Clustered, AWS does not provide a built-in way to create VPC endpoint access for Redshift Serverless in a different AWS account.

To make it possible, the simple workaround is presented as step 1.

Create a VPC Peering connection between Account A and Account B [manage routes in both ways]
Manage Security Groups

• For Lambda function Security Group in Account A:

add inbound rule on port TCP 5439 and choose Redshift Serverless SG as source

• For Redshift Serverless in Account B manage Redshift Serverless Security group:

add inbound rule on port TCP 5439 and choose Lambda function SG as source

It will automatically add the Account ID in front of SG.

In Account A, in Lambda execution role add Policy to assume IAM Role from account B, that has access to Redshift Serverless.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::<Account B ID>:role/role-on-source-account"
    }
}

In Account B, for the IAM Role edit Trust Policy to add arn from Lambda Execution Policy from Account A.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<Account A ID>:role/my-lambda-execution-role"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

For more detailed explanation, please refer to
AWS re:Post blog: How do I configure a Lambda function to assume an IAM role in another AWS account?

To make connecting to Redshift Serverless easier, you can use Redshift Data Api.

For the Lambda code, I decided to go with Python language where boto3 is used, particulary in this case boto3.client('redshift-data').
By creating the client this way, we are allowed to perform multiple functionalities such as execute_statement used for running the SQL queries.
For the whole list of functionalities, refer to this link.

Now, the only thing left is to implement the logic of your code and test the connection.

Reference:

boto3.amazonaws.com

Getting started - Amazon Redshift Serverless automatic mounting of AWS Glue Data Catalog

Wendy Wong for AWS Heroes ・ Jul 30 '23

#aws #database #analytics #tutorial

Analyze Sydney property prices with Amazon Redshift Serverless in GA

Wendy Wong for AWS Community Builders ・ Jan 29 '23

#aws #database #analytics #serverless

Amazon Redshift Serverless with CDK - Speaker Deck

Amazon Redshift Serverless を AWS CDK で構築してみる - 2022.08.31 nakanoshima.dev #29 LED-2!! (Let’s enjoy データ分析!!) -

speakerdeck.com