 A hands-on guide to Amazon ECS Gateway: set up the gateway once, connect services with one parameter and get HTTPS endpoints without building load balancers.

Amazon ECS Gateway:

## Introduction 

Amazon ‌ECS ‌Gateway ‌is a new, account-level feature that stands up and keeps up the ingress layer for your ECS services without you having to piece it together yourself. Think ALBs, TLS certificates, listener rules, target groups, plus the required security groups, all created and managed for you. AWS shared the launch on October 20, 2026, and it’s live across every commercial Region that supports ECS, with no extra cost attached (AWS News Blog).

What follows is the entire lab, start to finish. First comes the IAM role, then creating the gateway, then tying it to a cluster. From there, you spin up a service that ends up with its own HTTPS URL, and you never once hand-build a load balancer. To wrap up, I show a low-risk path for shifting an existing service onto the gateway in stages, and then, once you’re done, the cleanup steps to remove what you created.

## The ‌issue: ‌one ‌ingress setup per service 

Up to now, making an ECS service reachable from the outside has meant repeating the same checklist every single time. Someone on the team would spin up or hook up an ALB, request an ACM cert, wire in a WAF web ACL, poke the right holes in security groups, then keep all those moving pieces aligned as the service scaled or the definition changed.

Once you’re dealing with dozens of services, that repetition turns into a real drag. Releases take longer, small differences creep into configs across teams, and those differences stick around. And there’s a direct cost problem too: giving every service its own ALB also means paying for a separate load balancer for each one.

## ECS Gateway breaks that work into two clear lanes.

First, the platform team sets up the gateway a single time and bakes the standards into it, which subnets it lives in, what security groups apply, how TLS is handled, which listener is used, and what WAF rules sit in front. After that, they link the gateway to one or more ECS clusters.

Then, the application team keeps things simple. When they create or update a service, they add a gateway connector parameter, and that’s basically it. From there, ECS takes over and provisions the rest: the certificate, the DNS hostname, the listener rule, the target group, plus a security group that only allows traffic coming from the ALB.

## How ECS Gateway works

Under the hood, the gateway relies on host-based routing on the ALB, which lets up to 25 services share the same load balancer. When the first service connects, ECS creates the first ALB. As that ALB fills up, ECS adds another. When capacity isn’t needed anymore, it removes extras. Each service ends up with its own DNS hostname as soon as the provisioning finishes.

On every deployment, ECS checks every gateway tied to the cluster and connects the service to each gateway it can use. A gateway counts as compatible when the access type, public or internal, lines up with the connector filter, it sits in the same VPC as the service, and it spans every Availability Zone the service runs in.

![09-ecs-gateway-architecture.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/09_ecs_gateway_architecture_f6068e6ccb.png)

Think of it this way: the platform team builds the top row once, and ECS keeps the bottom row up to date on every deployment.

![11-ecs-gateway-key-limits.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/11_ecs_gateway_key_limits_5d5e7b0b98.png)

Source: [AWS News Blog.](https://aws.amazon.com/blogs/aws/introducing-amazon-ecs-gateway-a-fully-managed-ingress-solution-for-ecs-services/)

## What you need before the labs 

- An ‌AWS ‌account ‌with permissions to use ECS, IAM, EC2 (VPC) and Elastic Load Balancing
- AWS CLI (version updated to one that contains the create-gateway command)
- A VPC with at least two public subnets in different AZs (example uses us-east-1)
- An ECS cluster, for example "my-cluster" (Fargate is the easiest to use for the lab)
- A task definition with awsvpc network mode and a named port (for example "api")


```
export AWS_REGION=eu-central-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export CLUSTER=my-cluster
export GATEWAY=my-team-gateway
```


## Step-by-step lab

### Lab 1: Infrastructure IAM role

ECS ‌is ‌assuming ‌this role to create ALBs, security groups and certificates in my account. Create a role trusted by the ECS service and add permissions as specified in the ECS Gateway documentation.


```
cat > trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ecs.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

aws iam create-role \
  --role-name ECSGatewayRole \
  --assume-role-policy-document file://trust.json
```
  
  Note: verify the exact principal and managed policy for the gateway in the documentation before going to production.
  
  
![01-iam-role-trust-relationship.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/01_iam_role_trust_relationship_500f56d5a2.png)

### Lab 2: Creating the gateway in the console

83. In the ECS console open Gateways and choose Create gateway.
84. Enter the name my-team-gateway (must be unique in the account) and select ECSGatewayRole as the infrastructure role.
85. Choose the scheme: internet-facing for public traffic or internal for traffic inside the VPC.
86. Select the VPC and subnets in every AZ the services will use.
87. Under Additional settings configure the listener, port, maximum number of ALBs
88. Associate a cluster right away or later; in this lab we do it in Lab 4.

Caution: the name, scheme, VPC, subnets, IP address type, listener protocol and port cannot be changed after creation.

![02-gateway-configuration.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/02_gateway_configuration_169a1af5b6.png)

### Lab 3: Reviewing the gateway
Load balancers are empty as we  would expect.

![03-gateway-load-balancers-empty.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/03_gateway_load_balancers_empty_6bca42c813.png)

### Lab 4: Associating with a cluster

Associate gateway to the cluster so services on that cluster can use it. It's a many-to-many relation so one cluster can have for example a public and a private gateway.


```
aws ecs associate-gateway-with-cluster \
  --gateway $GATEWAY \
  --cluster arn:aws:ecs:$AWS_REGION:$ACCOUNT_ID:cluster/$CLUSTER
```
  
  
![04-associate-gateway-with-cluster.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/04_associate_gateway_with_cluster_9ddc1828be.png)

### Lab 5: Task definition with a named port
The ‌connector ‌references ‌the port by name, so you must name your port mapping.


```
{
  "family": "my-api-service",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [{
    "name": "api",
    "image": "public.ecr.aws/nginx/nginx:latest",
    "portMappings": [{
      "name": "api",
      "containerPort": 80,
      "protocol": "tcp"
    }]
  }]
}
```

```
aws ecs register-task-definition --cli-input-json file://taskdef.json
```

![05-task-definition-named-port.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/05_task_definition_named_port_da396b5caf.png)


### Lab 6: Service with a gateway connector 
This is the only step the application team does.  Add --gateway-connectors with the port name and the PUBLIC filter.


```
aws ecs create-service \
  --cluster $CLUSTER \
  --service-name my-api-service \
  --task-definition my-api-service:1 \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration 'awsvpcConfiguration={subnets=[subnet-AAAA,subnet-BBBB],securityGroups=[sg-XXXX],assignPublicIp=ENABLED}' \
  --gateway-connectors '[{"portName": "api", "filters": {"accessTypes": ["PUBLIC"]}}]'
```
  
  The ‌connector ‌may ‌also contain a healthCheck object (take its fields from the documentation). The service subnets must be in availability zones covered by the gateway.

![06-service-gateway-connector.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/06_service_gateway_connector_0b73fa89bd.png)

![07-gateway-load-balancer-created.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/07_gateway_load_balancer_created_0458a0d259.png)

## Testing and verification 

The service is ready when the gateway route moves to ACTIVE. Then copy the service's DNS hostname from the console and test it over HTTPS.


```
curl -I https://<service-hostname>
```
You should expect HTTP/2 200 and an nginx header, with a valid ACM certificate that ECS issued on its own.

![08-alb-listener-host-rule.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/08_alb_listener_host_rule_295c454fab.png)

![10-curl-https-test.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/10_curl_https_test_29982eac3b.png)


```
aws elbv2 describe-target-health --target-group-arn <target-group-arn>
```
## Pricing, pitfalls and cleanup
The gateway itself is free; you pay only for what ECS creates in my account: ALBs, ACM certificates, CloudWatch logs and metrics, and data transfer ([ECS pricing](https://aws.amazon.com/ecs/pricing/)).

What I watched out for in the lab:
1. Availability Zones: The availability zones of the services need to be the same. The availability zones of the services need to be a subset of those of the gateway. This is because the ALB only routes traffic to availability zones where it has a subnet. Easiest to just create both gateway and services in the same availability zones.
2.  Capacity: If the maxAlbCount is maxed out and there is no ALB with capacity, the deployment will fail. 25 services per ALB and 10 ALBs by default means 250 services per gateway.
3.  Immutable configuration: I spend a lot of thought on the name, scheme, VPC, subnets and listener because I can't change these values later on.
4.  Redeploying clears connections: Every time I deploy changes, ECS will revalidate the gateways on the cluster. It will associate the service with new gateways and remove routes from gateways that were disassociated.

Cleanup after the labs:

```
aws ecs delete-service --cluster $CLUSTER --service my-api-service --force
```
ECS ‌will ‌automatically ‌remove all gateway routes and per-service resources when the service is deleted, and the ALB will be removed if that was the last route for that ALB. Once that is complete, I disassociate and delete the gateway from the console and the ECSGatewayRole IAM role.

## Conclusion
The ‌main ‌difference ‌after the labs is the platform team defines the networking and security once, while the applications team gets an HTTPS endpoint with just one parameter (in create-service

If you’re working with ECS more broadly, take a look at our post on [ECS Managed Daemons,](https://www.cyberlab.rs/blog/ecs-managed-daemons) another recent addition that closes a long-standing gap in ECS. For more hands-on guides from the CYBERLAB team, you can browse the rest of [our blog.](https://www.cyberlab.rs/blog)

## Sources

- [Introducing Amazon ECS Gateway – AWS News Blog](https://aws.amazon.com/blogs/aws/introducing-amazon-ecs-gateway-a-fully-managed-ingress-solution-for-ecs-services/), October 20, 2026
- [Amazon ECS Gateway documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/gateway-overview.html)
- [Amazon ECS pricing](https://aws.amazon.com/ecs/pricing/)









a hands-on lab guide

Our colleague Andrija Vojnović, Lead DevOps Engineer at CYBERLAB, will be speaking at AWS Community Day Adria 2026, taking place on October 22 in Ljubljana, Slovenia.

One Firewall to Rule Them All:

Our colleague Andrija Vojnović, Lead DevOps Engineer at CYBERLAB, will be speaking at [AWS Community Day Adria 2026](https://awscommunityadria.com/sessions/ljubljana-1262316/), taking place on October 22 in Ljubljana, Slovenia.

His talk, "One Firewall to Rule Them All: Hub & Spoke on AWS," is scheduled for 11:30 in the Fabiani room and runs for 30 minutes.

## What It's About?

The session looks at how a Hub and Spoke architecture helps teams manage network complexity as AWS environments grow, from a single VPC to multiple VPCs spread across an AWS Organization. Andrija will walk through using AWS Cloud WAN as the global backbone tying regions together with a single declarative policy, and how to centralize traffic inspection, covering egress, ingress, and east-west traffic between spokes. 

## Why It's Worth Attending?

Expect concrete design trade-offs rather than a marketing pitch: where to place inspection, why egress inspection often stays regional even on a global network, and when centralization is actually worth the cost.

## Catch the Talk

If you're at AWS Community Day Adria, catch Andrija's talk! 


Hub & Spoke on AWS

Hands-on SuperPlane review: we built two opposite DevOps workflows on DigitalOcean to test guardrails, approvals, and alerting. Here's what held up.

SuperPlane Review:

> **Editor’s note:** This review is based on testing conducted in July. The product has continued to evolve since then, so some capabilities or limitations described below may have changed.

## What is SuperPlane?

[SuperPlane](https://superplane.com/) is an open source tool, still in beta, that sits in the middle. On one side, you have the tools you already use, like [Git](https://git-scm.com/), your CI, your cloud, and your monitoring. On the other, you have your actual infrastructure. SuperPlane sits between them.

The way it works is that you build a small graph of steps. Something like “deploy this,” then “wait for someone to approve,” then “check a metric,” then “send a message.” SuperPlane runs that graph for you, and it keeps running even if something restarts in the middle. You can also drop a human step anywhere you want, so nothing happens without approval unless you allow it.

![See the workflow, Control it like code](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/See_the_workflow_Control_it_like_code_031b5d8610.png)
_See the workflow, Control it like code_

The part we liked from the start is that each app is just files in Git. There is a `canvas.yaml` for the workflow and a `console.yaml` for the dashboard. So you can read it, review it, and keep versions of it like any normal code. You are not clicking around in some interface that nobody can track later.

The reason we care about this kind of tool at all is simple. In most teams, the “glue” between people and infrastructure is a mess of small scripts and things that only one person really understands. SuperPlane turns that glue into **something you can see, control, and improve** as a team.

## How We Tested SuperPlane: Two Real Workflows

Here is the thing, though: one workflow doesn't tell you much. If you only build the happy path, of course it works. You only find the real problems when you push a tool in both directions.

So we built two workflows, and we made them go opposite ways. Both of them talk to [DigitalOcean](https://www.digitalocean.com/), because that is the cloud we had a token for. One workflow sends commands out to the infrastructure. The other one reacts to something happening in the infrastructure. That is the full loop, and building both of them is where we actually learned something.

### Workflow 1: A Guarded DigitalOcean Deployment Pipeline

The first one is a deployment with some rules around it. A person clicks a button to start it. Before anything reaches [DigitalOcean](https://www.digitalocean.com/), [SuperPlane](https://superplane.com/) checks a few things:

- Is this the main branch? If not, stop.
- Is it during work hours, Monday to Friday, 9 to 5? If not, hold it.
- Did a human approve it? If not, wait.

Only after all three conditions are met does it actually redeploy the app on [DigitalOcean](https://www.digitalocean.com/), record that the deployment happened, and show it on a small dashboard.

The nice part is that each of those checks is just a small block in the file. Here is the “only during work hours” step, for example:

```yaml
- name: "Business hours only"
  component: "timeGate"
  configuration:
    days: ["monday", "tuesday", "wednesday", "thursday", "friday"]
    timeRange: "09:00-17:00" 
```
And the approval step is even shorter. This one just says, “Somebody has to approve before we continue”:

```yaml
- name: "Release approval"
  component: "approval"
  configuration:
    items:
      - type: "anyone"
```

This is not flashy, but it solves exactly the kind of operational problem that most teams get wrong: which branch you allow, when deployments are allowed, who has to approve, and how you keep a record of what happened. Normally, this lives in someone's head or in a script full of if-statements. Here, it was just a few blocks connected together, and we could see the whole thing at a glance.

![unnamed (4).png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/unnamed_4_685d7da047.png)

###Workflow 2: Auto-Rebooting a Droplet on a CPU Spike
The second one is the opposite direction. Every few minutes, [SuperPlane](https://superplane.com/) looks at a server's CPU. If it goes over 80 percent, it shows an alert, asks a person to approve a reboot, reboots the server, and writes down what happened.

The check itself is basically one line. This block reads the metric from the previous step and checks whether the average CPU usage is above 80 percent:

```yaml
- name: "CPU above 80%?"
  component: "if"
  configuration:
    expression: '$["Read droplet metrics"].data.avgCpuUsagePercent > 80'
```

Then you connect the “yes” and “no” paths. In SuperPlane, the lines between steps carry a channel, so a check like this has a true side and a false side:

```yaml
edges:
  - sourceId: "CPU above 80%?"
    targetId: "High CPU detected"
    channel: "true"
  - sourceId: "CPU above 80%?"
    targetId: "Droplet healthy"
    channel: "false"
```

So the “true” path goes to the alert and reboot, while the “false” path marks the server as healthy and stops.

This is the “notice something and do something about it” pattern: the reactive half of running infrastructure and often the more challenging half to build well. Testing this workflow also showed us where[ SuperPlane](https://superplane.com/)’s event support could be expanded.

## What We Liked About SuperPlane
The rules, or guardrails, are easy to add: “only from main,” “only during work hours,” and “wait for approval.” These are not things we had to code. They are just blocks you drop into the flow, and each block has a clear yes path and no path.

If your problem is people deploying whenever and however they feel like, this part alone is worth it.

You get storage and a dashboard almost for free. Each app can keep its own data, and the dashboard reads straight from that. We made a table of incidents and a “highest CPU we've seen” number without setting up a database or building a frontend. That saved us real time.

Everything is files plus an API. It is all canvas.yaml and console.yaml, with a normal draft, commit, and publish flow, like Git. We wrote the files and pushed them through [SuperPlane's API](https://docs.superplane.com/concepts/api-reference/).

The interface, the files, and the API are just three views of the same thing. If you like doing things as code, you will feel at home here.

## SuperPlane Integrations and Advanced Features
We only built two workflows, but while we were in there, we looked at the rest of it, and there is a lot more that [SuperPlane](https://superplane.com/) can do. A few things stood out.

![SuperPlane Integrations and Advanced Features](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Super_Plane_Integrations_and_Advanced_Features_d6b21d8138.png)
_Connect the tools you wanted to have & control the flow._

First, it connects to far more than clouds. There are around 47 integrations, and they cover much of the tooling a team already uses: CI tools like GitHub and GitLab; incident and on-call tools like [PagerDuty](https://www.pagerduty.com/) and [Rootly](https://rootly.com/); chat tools like Slack, Discord, and Teams; and monitoring tools like [Datadog](https://www.datadoghq.com/), [Grafana](https://grafana.com/), Prometheus, and Sentry. So a workflow does not have to stay inside one tool. A realistic one might start when an incident is opened, pull the last few deployments and some health numbers, post a summary to Slack, and open a ticket, all in one graph.

Second, there are more building blocks. You can loop over a list and run the same step for each item, and you can wait for several things to finish before moving on. That "wait for all of them" piece is how you would build something like a release that only continues once three different services are ready.

Third, there is an escape hatch for anything that does not have its own integration. There are plain HTTP and GraphQL steps, and an SSH step that runs a command on a server. It is not native, but you can reach the [Kubernetes](https://www.cyberlab.rs/blog/kubernetes-development-skaffold) API over HTTP or run `kubectl` over SSH, like this:

```yaml
- name: "Restart the deployment"
  component: "http"
  configuration:
    method: "POST"
    url: "https://my-cluster.example.com/apis/apps/v1/namespaces/prod/deployments/api"
```
It is not as clean as a native integration, but it is a practical escape hatch that means you are rarely completely stuck.

Fourth, it can call AI models in the middle of a workflow. There are blocks for [Claude](https://claude.ai/) and [OpenAI](https://openai.com/), so you could have a step summarize an incident or draft a message, and then put a human approval right after it so nothing goes out without someone reading it first. There is also a built-in assistant that helps you build and debug the workflows themselves, and the same permission rules apply whether a person or an AI agent is the one doing something.

## Is SuperPlane Right for You? Requirements and Limitations
You do not have to be a developer to use SuperPlane, but you do need to understand the infrastructure you are connecting to it. You need to know about tokens and APIs, and what an app or a server actually is. You also need to understand the difference between an event, which is something being pushed to you, and polling, which is you asking again and again. That difference decides a lot about what you can and cannot build. And you should be fine with basic YAML and with thinking in terms of flows and graphs. Someone with no technical background would really struggle to set this up on their own.

## Final Thoughts: Is SuperPlane Worth Trying?
[SuperPlane](https://superplane.com/) solves a real problem. It takes the messy glue between your team and your infrastructure and turns it into workflows you can see, govern, and keep in version control. The guardrails, built-in storage and dashboards, and files-plus-API approach make it much easier to turn operational knowledge into a system the whole team can understand and use. We enjoyed working with it.

We think it gives teams a structured way to replace scattered scripts and manual coordination with visible, governed workflows. It is still a beta product with room to grow, but the foundation is already useful, and the open source version makes it possible to test that value against your own infrastructure.

If any of this sounds like a problem you are dealing with, that is the kind of thing we help teams work through at [CYBERLAB](https://www.cyberlab.rs/). Our advice is: do not trust our write-up, and do not trust anyone's demo either. Take the open source version, connect it to something real, and push it in both directions as we did. You will learn more in one afternoon of building than in a week of reading. And if you want a hand while you test it, just reach out.




We Tested This DevOps Orchestration Tool Both Ways

A hands-on guide to ECS Managed Daemons, AWS's answer to Kubernetes DaemonSets, with step-by-step setup for running agents like CloudWatch on ECS.

ECS Managed Daemons:

Every DevOps engineer who is working with ECS and managing monitoring for services knows how hard it can be. You have more than 30 services. A new version of the CloudWatch Agent is released. To update services, you're coordinating with five application teams, creating 30 new task definition revisions, and triggering 30 rolling deployments - just to bump an agent version. One mistake and you have a gap in your monitoring. \
 \
[Kubernetes](https://kubernetes.io/ ) had a clean answer to this problem for years: the DaemonSet. One resource, one agent per node, managed independently of applications. Now, ECS is catching up, also. \
 \
[AWS announced ECS Managed Daemons in April this year](https://aws.amazon.com/blogs/aws/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/). This is a native construct that decouples operational agents from application task definitions. In this post, I'll walk you through what it is, how it works, and how to set it up using the AWS Console.

**In short:** 

ECS Managed Daemons are a native AWS construct that decouples operational agents - like the CloudWatch Agent - from your application task definitions, much like a Kubernetes DaemonSet. 

Instead of bundling a monitoring sidecar into every service and redeploying dozens of services just to bump an agent version, you define the daemon once at the cluster level and ECS guarantees exactly one agent per instance - started before your apps and drained last, so monitoring never has a gap. 

Platform teams can update agents independently of application teams, with automatic start-before-stop rollouts and circuit-breaker rollback. The one catch: Managed Daemons work only with ECS Managed Instances capacity providers - not the classic EC2 launch type or Fargate. 

This post covers what they are, how they work, and how to set one up from the AWS Console.

## The Problem with the Sidecar Pattern

Before Managed Daemons, the standard way to run a monitoring agent for your application on [ECS](https://aws.amazon.com/ecs/) was the sidecar pattern: add an agent container directly inside your task definition. This is a problem for more than one reason:

* **Tight coupling:** If I want to update a new version of the monitoring agent, I need to update the task definition, which will create a new revision, and I need to redeploy the whole service, which includes the application container
* **Resource waste:** Every task runs a side container for monitoring. If you have 30 tasks, you will have 30 monitoring containers running.
* **Inconsistency risk:** Teams can accidentally omit the sidecar, leaving some services unmonitored without anyone noticing.

## What Are ECS Managed Daemons?

ECS Managed Daemons are a dedicated service for operational agents that is completely separate from your application task definitions. You define it once at the cluster level, and you are assured that it will execute for every service.

Key benefits:

* **One daemon per instance:** ECS creates exactly one daemon task per managed instance
* **Start before applications:** The daemon is guaranteed to be running before any application task is placed on that instance.
* **Drain last:** When an instance is being replaced or drained, the daemon is the last thing to stop, ensuring no gap in observability coverage.
* **Independent lifecycle:** Platform teams can update the daemon without touching application task definitions or coordinating with application teams.

One thing to keep in mind before you get excited: Managed Daemons only work with ECS Managed Instances capacity providers. Classic EC2 launch type and Fargate are not supported. 
 
## Step-by-Step: Setting Up a Managed Daemon via the Console

Before getting started, we need to create:

* An ECS cluster with a Managed Instances capacity provider configured
* An IAM task execution role
* The container image you want to run as a daemon (we'll use the CloudWatch Agent) 
* Created log group /ecs/cloudwatch-agent-daemon

### Step 1: Create a Daemon Task Definition

![slika 1png.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_1png_9590d0fe26.png)

Configure the following:

* **Daemon task definition family:** Give it a name, like cloudwatch-agent-daemon
* **Task execution role:** Select ecsTaskExecutionRole
* **Create a CloudWatch Agent Task Role:** Create a new IAM Task role, with name **CloudWatchAgentTaskRole,** and attach** CloudWatchAgentServerPolicy** AWS managed policy
* **CPU:** 1 vCPU
* **Memory:** 512 MB

Under Container, add your agent container:

* **Name:** cloudwatch-agent
* **Image URI:** public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest
* Set configuration for CW Agent; create one env variable:


```
key: CW_CONFIG_CONTENT
value: {\"metrics\":{\"metrics_collected\":{\"cpu\":{\"measurement\":[\"cpu_usage_idle\"],\"metrics_collection_interval\":60}}},\"logs\":{\"metrics_collected\":{\"emf\":{}}}}
```
![slika 2.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_2_bc9df2d3f8.png)

### Step 2: Create the Daemon on Your Cluster

Go to Clusters tab → Select your cluster → Open Daemons tab
![slika 3.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_3_5fed36817f.png)

Click Create daemon and configure:
* **Daemon name:** e.g., monitoring-agent
* **Daemon task definition:** Select the family you just created
* **Capacity provider:** Select your Managed Instances capacity provider
* **Drain percentage:** Controls the pace of rolling replacements during updates (50% means at most half your instances can be in the drain state simultaneously)

![Slika 4.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Slika_4_ae8141d024.png)

### Step 3: Verify the Daemon is Running

Create a testing service which will be monitored (e.g., nginx, hello world).

You'll observe that the daemon was already running before the application task was placed - no manual intervention required.
![Slika 5.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Slika_5_32c06917b4.png)

Before the nginx service deployment, there was no instance of the cloudwatch-agent daemon, but when the deployment of the service started, the cloudwatch agent deployed one task first, and then the deployment of the service continued.

## How Updates Work

In this part, I will explain the main advantage of daemons over the sidecar pattern. When you need to update the agent to a new version, ECS handles the rollout automatically using a "start before stop" strategy.

The old daemon on the outgoing instance stays alive until all application tasks have successfully migrated to a new instance running the updated daemon. Service will have one available agent in every moment, there is no gap in monitoring or logs shipping.

ECS also includes automatic rollback via circuit breaker. If the new daemon fails health checks during a rollout, ECS stops the replacement and rolls back, protecting your services.

## When to Use Managed Daemons?

Managed Daemons are a great fit for any agent that needs to run on every instance, independently of which applications are deployed. 

When NOT to use Managed Daemons:

* Application-specific sidecars that only make sense alongside a specific service
* Init containers or one-time setup tasks

## Conclusion

My recommendation is to use Managed Daemons every time there is a need for a sidecar agent. One of the biggest wins for me is that I can work separately on updating or creating agents without clashing with developers' work and progress. And there's another thing worth mentioning - no more gaps in monitoring.

The only problem I have currently is that on some projects, we are not using managed instances for ECS, and there are no plans in the future for using them, so we are limited to going the old way. 

If you're currently running monitoring agents as sidecars on ECS Managed Instances, this feature is worth evaluating immediately. The migration path is straightforward - extract the agent container from your task definitions, create a daemon task definition, and let ECS manage the rest.

Found this useful? [Check out our other blog posts for more insights on cloud architecture](https://www.cyberlab.rs/blog ).

## Resources
* [AWS Blog: Announcing managed daemon support for Amazon ECS Managed Instances](https://aws.amazon.com/blogs/aws/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/)
* [Amazon ECS Managed Daemons Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons.html)
* [Amazon ECS Managed Instances product page](https://aws.amazon.com/ecs/managed-instances/)
* [CloudWatch Agent on ECR Public Gallery](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent)

The DaemonSet Equivalent ECS Was Always Missing

For the third year in a row, CYBERLAB joined the KTJ Club Business Challenge running 1,237 km to support a child in need of ongoing medical treatment.

Running for Neda: 

For the **third year in a row,** the [CYBERLAB](https://www.cyberlab.rs/meet-the-team) team joined the [KTJ Club](https://www.linkedin.com/company/ktj-club/posts/?feedView=all) Business Challenge. A month-long initiative where companies across Serbia convert their employees' kilometers into donations for children in need. This May, our team ran **1,237 kilometers** and raised **100.000 RSD** to support the ongoing medical treatment of a little girl named [Neda Ranđelović](https://pokrenizivot.com/cir/korisnik/neda-randjelovic-239). Here's what that month actually looked like from the inside.
## Our Why - Neda Ranđelović 
Neda was born after a healthy, regularly monitored pregnancy. However, complications during delivery later resulted in a diagnosis of cerebral palsy.

When we heard about Neda’s story, we were deeply moved by her strength and the dedication of her family. During the first year of the challenge, we decided to direct our fundraising efforts toward helping Neda. By the end of that month, we had built a genuine connection with her and her family, who, in turn, supported and cheered us on throughout the entire challenge. Seeing how much the treatment had helped her progress made us proud to have played even a small part in her recovery.

Earlier this year, when we heard that Neda needed a new cycle of therapy, the answer was simple: we wanted to help again.

![2.jpg](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/2_7572d98eff.jpg)
## About the KTJ Club Business Challenge
The **KTJ Club Business Challenge** founded in April 2024, a simple idea by KTJ Club: turn everyday kilometers into meaningful support for children in need. From the start, six companies joined the initiative, and **CYBERLAB was among them**. Back then, 190 colleagues took part. This year, that number grew to 26 companies with more than 1,000 participants.

The concept was designed from the ground up for everyday runners, not just seasoned athletes. Teams of up to 25 colleagues form a running squad; companies could register more than one, and convert their kilometers into donations for a child or children's institution of their choice. Every kilometer counts, every step carries a meaning beyond the finish line.
## How a Shared Purpose Brought Our Team Closer
On paper, the challenge was simple: run, log kilometers on Strava, repeat. In practice, it quietly rewires how a team operates for an entire month.
For those joining the challenge for the first time, the motivation came naturally from the team itself. There was always someone in the group chat sending an invite for a run, and **when you run with others, you inevitably push past what you thought you could do**. A kilometer or two more than planned, a limit quietly crossed. 

**The company played its part too** by providing our runners with proteins and healthy food throughout May, giving the whole initiative an extra push.

And then there was **Bojan Čakar**, **our colleague and unofficial captain, who kept the team's energy up throughout the month with protein pancakes and shakes**. By the end of May, that same energy carried a part of the team all the way to Fruška Trail, 15 kilometers through Fruška Gora, a serious challenge by any standard, and proof that what started as a charity run had become something the team genuinely wanted to push further.

Without overthinking it, that's how 1,237 kilometers happened logged across two countries, with teammates running in Novi Sad, Belgrade, Bijeljina, and Banja Luka.
![KTJ Kraj izazova 2026 (1).jpg](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/KTJ_Kraj_izazova_2026_1_bcc68383e4.jpg)
## More than a finish line
By the end of May, we were all in better shape than when we started, and not just physically. We pushed past our own limits, ran through rain without thinking twice, and finished the challenge as a tighter, closer team.

As individuals, we grew. As a collective, we bonded. And as part of a wider community, we made a contribution that we hope made a difference.
When it comes to helping others, no gesture is too small. Every kilometer, every donation, every share matters. If you'd like to add your voice to this story and support Neda's ongoing treatment, you can do so right now by sending an SMS with the text **239** to **3800**.

As for us,  we had a great time, and this is far from the only initiative we're part of. If you'd like a peek into our team culture and what we're up to, we'd love to have you follow along. Stay connected with us on [LinkedIn](https://www.linkedin.com/company/69988472/admin/notifications/all/), [Instagram](https://www.instagram.com/wearecyberlab/), and [Facebook](https://www.facebook.com/cyberlabsolutions/).




The Story Behind CYBERLAB's 1,237km

The “Claude Code 101” event in Novi Sad showcased practical AI-assisted development with Claude Code, led by Uroš Petrić from CYBERLAB.

How AI Is Changing the Way We Write Code:

On Tuesday, **April 21st, 2026,** we hosted an event at [Prostor](https://www.facebook.com/prostorgradic/?locale=sr_RS) in Novi Sad titled **“Claude Code 101: From Zero to Full Potential.”** Interest in the event was exceptionally high, with 100 attendees joining us, including software engineers, frontend and backend developers, students, and IT enthusiasts.

The venue was at full capacity, reflecting how quickly AI-assisted development tools have evolved from a curiosity into an essential part of everyday work in modern software teams.

## Speaker: Uroš Petrić - Software Engineer with Hands-On AI Development Experience

The session was delivered by our colleague [Uroš Petrić](https://www.linkedin.com/in/urospetric/), [Software Engineer](https://www.cyberlab.rs/meet-the-team) at [CYBERLAB](https://www.cyberlab.rs/), who brings extensive experience in application development and the practical use of AI tools in everyday engineering work. Within [CYBERLAB](https://www.cyberlab.rs/), Uroš successfully led the development of an internal application from idea to production in just a few weeks, with AI assistance playing a key role throughout the entire process. He regularly shares his knowledge and experience with colleagues through internal knowledge-sharing sessions.

![Software Engineer at CYBERLAB Leading hands-on AI-assisted development with Claude Code](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/1_2_3ca0a3f73f.png)

In this session, he demonstrated what a real-world AI-assisted development workflow looks like in practice, and how tools like [Claude Code](https://claude.ai/) can become a natural extension of a developer’s daily toolkit.

## What Does AI-Assisted Development Look Like in Practice?

Uroš walked participants through the complete picture of working with [Claude Code](https://claude.ai/), from understanding what a coding assistant actually is, to configuring advanced automation, parallel agents, and external integrations. The presentation covered the following core topics:

#### 1. Coding Assistant - Beyond the Chat Interface

The audience learned how [Claude Code](https://claude.ai/) differs from a simple chat interface and how it bridges the developer and the language model through a structured tool layer. **A key insight:** the language model does not execute actions itself; it requests the coding assistant to perform them, which means the developer retains full control over what happens in their codebase.

#### 2. Tools - What Claude Code Can Do

Uroš walked through the full set of built-in tools available to [Claude Code](https://claude.ai/), including Bash, Edit, Glob, Grep, Read, Write, WebFetch, WebSearch, and the Agent tool for launching subagents. Participants gained an understanding of how Claude decides which tool to use and how additional capabilities can be added through MCP server integrations.

#### 3. Context - Giving Claude What It Needs

One of the most practical segments of the talk focused on context management. Providing the right information and avoiding irrelevant or misleading context directly determines the quality of Claude's output. Uroš explained how context windows work, why they fill up, and how to manage them effectively during long sessions.

![PROSTOR I Novi Sad I CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_Claude_Code_101_From_Zero_to_Full_Potential_e4b707dfb4.jpg)
#### 4. CLAUDE.md and Auto Memory

The session covered CLAUDE.md, the single most impactful configuration file in any [Claude Code](https://claude.ai/) project. Loaded automatically at the start of every session, it acts as Claude's persistent memory,  documenting the tech stack, architecture, build commands, workflows, and project-specific gotchas. Alongside CLAUDE.md, Uroš introduced Auto Memory, which accumulates knowledge across sessions without any manual effort, storing learnings in plain markdown files that Claude reviews at the start of each new conversation.

#### 5. Planning and Thinking Modes

Participants learned how to shift [Claude Code](https://claude.ai/) into different operational modes depending on the task at hand. Plan Mode restricts Claude to read-only tools, allowing it to thoroughly explore the codebase and produce a detailed implementation plan before touching a single file. Thinking modes, from basic Think to Ultrathink, give Claude progressively more reasoning capacity for complex logic problems, difficult debugging scenarios, and algorithmic challenges. Uroš also clarified an important distinction that often causes confusion: effort and thinking are separate controls, and increasing one does not automatically increase the other.

#### 6. Commands

The talk explained how commands extend Claude Code's functionality through simple slash notation. Participants saw examples of both built-in commands, such as /compact, /clear, /memory, and /agents, as well as custom commands stored in the .claude/commands directory. The $ARGUMENTS pattern for parameterized commands proved particularly popular among attendees.

#### 7. Skills

Skills are markdown guides that Claude auto-invokes based on the context of a conversation. Unlike commands, which require manual triggering, skills activate automatically when Claude recognizes a relevant situation. Uroš demonstrated how a well-written description field in a SKILL.md file is the key to reliable auto-activation, and walked through several practical skill ideas including code-review, testing-patterns, explain-code, and docker-deploy.

![CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_7e15908ce3.jpg)

#### 8. Agents and Subagents

The second half of the session was dedicated to subagents, which drew considerable attention from the audience. Subagents are specialized AI assistants that handle specific tasks in fully isolated contexts, each running with its own system prompt, tool access, and independent permissions. Through concrete examples, Uroš demonstrated how subagents help preserve the main conversation context, enforce constraints on tool usage, enable parallel task execution, and even control costs by routing lighter tasks to faster, cheaper models. He also walked through the three built-in subagent types, Explore, Plan, and General Purpose, each with different model and tool configurations suited to different stages of a workflow.

#### 9. MCP Servers

Model Context Protocol servers unlock integrations with external services directly from Claude Code. The talk covered a range of practical integrations, including GitHub for repository and pull request management, Figma for design-to-code workflows, Notion for workspace connectivity, Slack for messaging and data retrieval, and Playwright for automated browser testing. Participants left with a clear picture of how MCP transforms Claude Code from a standalone coding assistant into a connected development hub.

#### 10. Hooks

The final topic covered Hooks, one of the most powerful and underused features in Claude Code. Hooks allow developers to run a command before or after Claude Code performs any action, and optionally block that action entirely. Use cases demonstrated during the session included automatically running a code formatter after every file edit, blocking commits that introduce deprecated function calls, checking for TODO comments and logging them to a file, and enforcing naming conventions across the codebase. Participants saw how PreToolUse hooks can serve as safety gates and can block an action by returning exit code 2, while PostToolUse hooks provide a way to react to Claude's actions without interrupting the flow.

![Q and A](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/NEM_187_resized_7efcc9e449.jpg)

## Learning Resources

At the end of the presentation, attendees received a curated list of resources for further exploration:

* [Claude Code in Action course](anthropic.skilljar.com/claude-code-in-action) 
* [Claude Code official documentation](docs.anthropic.com/claude-code) 
* [Claude Code Templates](https://www.aitmpl.com/)
* [Claude Code Best Practices](https://github.com/shanraisshan/claude-code-best-practice)
* [CYBERLAB blog](www.cyberlab.rs/blog) 

These materials provide an excellent starting point for anyone looking to integrate Claude Code into their daily development workflow.

## Networking 

After the presentation, participants enjoyed an informal networking session, where they had the opportunity to talk with Uroš and the [CYBERLAB](https://www.cyberlab.rs/) team about their projects, questions, and early experiences with Claude Code. Topics ranged from practical CLAUDE.md setups and skill configurations to broader questions about where AI-assisted development is heading and how teams can adopt it gradually without disrupting existing workflows.
![Networking I CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_I_Claude_Code_81335a7dde.jpg)

## Conclusion

The **"Claude Code 101: From Zero to Full Potential"** event demonstrated that the local developer community is actively exploring AI tools and looking for concrete, practical guidance on how to use them well. AI-assisted development, intelligent context management, and autonomous coding agents are becoming increasingly relevant across all types of software projects, and this meetup once again highlighted how shared learning strengthens the entire community.

See you at the next [CYBERLAB](https://www.cyberlab.rs/) event!

We're always happy to share our knowledge and experiences. Feel free to follow or reach out to us on [LinkedIn](https://www.linkedin.com/company/cyberlabsolutions) |[ Facebook](https://www.facebook.com/cyberlabsolutions/) |[ Instagram](https://www.instagram.com/cyberlabsolutions/). 


Insights from a Community Talk on Claude Code and AI-Assisted Development

Pozivamo vas da nam se pridružite na događaju koji organizujemo na temu “Claude Code 101: From Zero to Full Potential", 21. 4. sa početkom od 18h u Prostoru, u Novom Sadu.

Claude Code 101:

Pozivamo vas da nam se pridružite na događaju koji organizujemo na temu **“Claude Code 101: From Zero to Full Potential"**, **21. 4.** sa početkom od **18h** u [Prostoru](https://www.facebook.com/prostorgradic/?locale=sr_RS), u Novom Sadu.

Evo svega što trebate da znate:

## Ko je predavač?

U ulozi predavača naći će se [Uroš Petrić](https://www.linkedin.com/in/urospetric?skipRedirect=true&miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAACIr7FIBfVR4sK3Q_p4JwLgaqomQg9uoimg), softver inženjer sa višegodišnjim iskustvom u razvoju aplikacija i aktivnoj primeni AI alata u svakodnevnom radu. U okviru [CYBERLAB](https://www.cyberlab.rs/)-a Uroš je, uz pomoć AI, uspešno vodio razvoj interne aplikacije od ideje do produkcije za svega nekoliko nedelja. Svoje znanje i iskustvo Uroš redovno deli sa kolegama kroz interne knowledge sharing sesije.

Na predavanju vas očekuju jasni uvidi u to kako AI alati mogu da unaprede svakodnevni razvojni proces, bez obzira na tehnologiju koju koristite.

## O čemu će biti reči?

Ovom prilikom, Uroš će govoriti o tome:

* Šta je Claude Code i kako funkcioniše kao coding assistant
* Ključnim konceptima: Tools, Context, CLAUDE.md, Memory, Commands, Skills, Agents, MCP Servers i Hooks
* Kako efikasno kontrolisati razgovor i maksimalno iskoristiti Claude Code u svakodnevnom radu

## Kome je predavanje namenjeno?

* Developerima i softver inženjerima koji žele da ubrzaju svoj workflow
* IT profesionalcima koji žele da razumeju kako AI menja način na koji se piše kod
* Svima koji su radoznali, predavanje kreće od osnova i pokriva sve najbitnije celine

## Zašto da se prijavite?

Ova tema može biti posebno zanimljiva ukoliko:

* Još niste počeli da koristite coding assistente, ali razmatrate tu mogućnost
* Koristite AI alate u svom radu, ali niste sigurni da li ih koristite na optimalan način
* Tražite konkretne tehnike i prakse koje možete odmah primeniti u svom projektu

Pozivamo vas da nam se pridružite i steknete vredne uvide koji će vam pomoći da izvučete maksimum iz Claude Code-a u svakodnevnom radu.

## Kako da se prijavite?

Broj mesta je ograničen, stoga je neophodno da potvrdite svoje prisustvo popunjavanjem forme koja se nalazi u nastavku. Prijave su otvorene **ponedeljka, 20. aprila do 12h** a u slučaju popunjavanja svih mesta, prijave će biti zatvorene i ranije.

## **[PRIJAVITE SE OVDE 👈](https://forms.gle/c4wgUrTq9PfYx1xe8)**

Nakon predavanja vas očekuje networking i neformalno druženje tokom kojeg ćete imati priliku da sa Urošem diskutujete o različitim temama i postavite sva pitanja koja vas zanimaju o korišćenju Claude Code-a i AI alata u svakodnevnom radu. Vidimo se u **utorak, 21. aprila u 18h** u [PROSTOR](https://share.google/om60XImwwLZ5tjHkE)-u! 🙂


From Zero to Full Potential

CYBERLAB is now an AWS Select Tier Services Partner, recognized for technical expertise, secure and scalable cloud solutions, and proven customer success.

CYBERLAB Achieves:

We’re proud to announce an important milestone for [CYBERLAB](https://www.cyberlab.rs/): **we are now an [AWS Select Tier Services Partner](https://aws.amazon.com/partners/services-tiers/)**. This recognition reflects our technical expertise, strong customer success record, and commitment to delivering secure, scalable, and high-performing cloud solutions.

At a time when organizations face increasing cloud complexity, rising cost pressure, and stricter security demands, this achievement reinforces our role as a **trusted engineering partner** that helps teams move faster with confidence.

## What AWS Select Tier Status Means 

The AWS Select Tier Services Partner designation is awarded to companies that meet strict standards across technical capability, customer success, and operational excellence. For us, it validates that we:

* Design and deliver architectures aligned with AWS best practices for **security, reliability, and performance**
* Successfully support **mission-critical and production workloads** on AWS
* Apply **deep, hands-on expertise** across cloud infrastructure, [DevOps](https://www.cyberlab.rs/devops) automation, and modern application platforms

As a Select Tier Partner, we gain access to enhanced AWS enablement, direct technical guidance, and closer collaboration with AWS experts, allowing us to continuously refine how we design, build, and operate cloud platforms for our partners.

## Tangible Benefits for Our Partners

This milestone translates directly into measurable value for the organizations we work with:

* **Secure and resilient cloud foundations** designed for real production traffic, not just proofs of concept
* **Scalable architectures** that adapt to growth, peak demand, and long-term evolution
* **Faster delivery and innovation**, combining AWS-native services with our DevOps-first approach
* **End-to-end ownership**, from cloud strategy and migration to optimization, automation, and ongoing operations

Whether you’re modernizing legacy systems, migrating to AWS, or optimizing an existing environment, [we](https://www.cyberlab.rs/meet-the-team) help you reduce risk, improve reliability, and shorten time to value.

## What Sets Us Apart

Many organizations hold AWS partner status. What differentiates us is how we deliver and operate:

* **A DevOps-first mindset** focused on automation, observability, and reliability from day one.
* **Extensive experience running complex, production-grade environments**, including high-availability and regulated workloads.
* **Full lifecycle responsibility**: we design, build, operate, and continuously improve cloud platforms.
* **A partner-led delivery model** where we own solution quality and customer experience end-to-end.

AWS provides us with tools and technical support, but we remain fully accountable for results.

## Our Commitment Going Forward

We see this designation not only as a recognition of our past achievements but also as a foundation for **future innovation and collaboration**. It strengthens our ability to help clients navigate cloud adoption, modernization, and optimization, while staying focused on what matters most: **delivering reliable systems and measurable business outcomes**.

If you’re planning a cloud migration, platform modernization, or optimization initiative, we are ready to support you with proven expertise and hands-on delivery.

Discover how [CYBERLAB](https://www.cyberlab.rs/), together with [Amazon Web Services](https://aws.amazon.com/), can help your business build, scale, and operate with confidence in the cloud. [Contact us](https://www.cyberlab.rs/contact) today to get started.


AWS Select Tier Services Partner Status

Over 150 participants came together at our New Year’s Charity Pub Quiz in Novi Sad, raising 1,400 EUR to support Minja, Strahinja, and Vukašin in their fight against a rare ADSL gene mutation.

New Year’s Charity Pub Quiz:

On **December 23, 2025,** we held our[ New Year’s Charity Pub Quiz](https://www.cyberlab.rs/blog/cyberlab-novogodisnji-humanitarni-pub-kviz-minja-strahinja-vukasin) at The Pub in Novi Sad, bringing together colleagues, friends, and members of the local community for an evening dedicated to knowledge, teamwork, and giving back.

Thanks to the generosity of all participants, **we raised and donated 1,400 EUR** to support **Minja, Strahinja, and Vukašin** in their fight against a rare ADSL gene mutation and to help fund the treatment they needed.
![New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_7e762b2e07.jpg)

## A Tradition Built by People and Ideas

The story of our quiz began a few years ago as an internal [CYBERLAB ](https://www.cyberlab.rs/)initiative, launched by **Dragan Perić** and **Andrija Vojnović**. What started as a small team event gradually grew into a tradition that brings people together beyond the company walls.

Last year, this tradition took an important step forward with the [DragiAndro Quiz Special](https://www.cyberlab.rs/blog/dragiandro-quiz-for-childrens-smile), the first open charity edition of the quiz, which marked the transition from an internal gathering to a community-focused event with a humanitarian goal.

Building on that momentum, the concept continued to evolve through the efforts of **Nemanja Radoičić** and **Bojan Baškalo**, who brought new energy to the format through the **BN Quiz** and helped further strengthen the quiz culture within the team. This year, for the first time, these initiatives came together in a joint charity event with an even greater impact.

![New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin - Hosts](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_Bojan_Baskalo_Andrija_Vojnovic_Nemanja_Radoicic_a65d9aa698.jpg)

## Turning Knowledge into Support

A great atmosphere, friendly competition, and a shared sense of purpose marked the quiz night. With a symbolic ticket price and strong community participation, the event showed how small individual contributions can turn into meaningful collective support.

Raising **1,400 EUR** in a single evening is a clear example of what can be achieved when people come together around a common goal.

![Participants in a quiz ](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_61511c83dd.jpg)

## Thank You for Making It Possible

We would like to thank [Elite Tennis Academy](https://tennisacademyelite.com/), [Bossi Pizza](https://www.facebook.com/p/Bossi-Pizza-100052412786270/), and [Arena Cinaplex](http://www.arenacineplex.com/) for supporting the quiz and providing prizes. A special thank-you goes to [Andrija, Nemanja, and Bojan](https://www.cyberlab.rs/meet-the-team), whose dedication and enthusiasm helped turn an idea into a successful charity event.

Most of all, thank you to everyone who participated and contributed.

![Quiz Question](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_67e0572ae0.jpg)

## United for a Common Goal

This quiz once again showed how much can be achieved through collaboration and shared effort. By combining knowledge, teamwork, and community support, we created an event with a real and measurable impact

Although the quiz night is over, the initiative continues. We invite everyone who would like to contribute further to support Minja, Strahinja, and Vukašin by following the donation instructions **[here](https://www.budihuman.rs/korisnik/1417/minja-lapcevic)**. 

Stay connected with us on [LinkedIn](https://www.linkedin.com/company/69988472/admin/notifications/all/), [Instagram](https://www.instagram.com/wearecyberlab/), and [Facebook](https://www.facebook.com/cyberlabsolutions/) to keep up with future initiatives.


We're Wired In.
Latest news.

Amazon ECS Gateway:a hands-on lab guide

One Firewall to Rule Them All:Hub & Spoke on AWS

SuperPlane Review:We Tested This DevOps Orchestration Tool Both Ways

ECS Managed Daemons:The DaemonSet Equivalent ECS Was Always Missing

Running for Neda: The Story Behind CYBERLAB's 1,237km

How AI Is Changing the Way We Write Code:Insights from a Community Talk on Claude Code and AI-Assisted Development

Claude Code 101:From Zero to Full Potential

CYBERLAB Achieves:AWS Select Tier Services Partner Status

New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin

ELEVATE
YOUR
CLOUD.

We're Wired In. Latest news.