DEV Community: Nishath J P

[Boost]

Nishath J P — Mon, 27 Jul 2026 04:53:47 +0000

Nishath J P

Jul 27

Building a Secure Blue/Green Deployment Pipeline on Amazon ECS with Jenkins

#aws #devops #cloud #cicd

5 min read

Building a Secure Blue/Green Deployment Pipeline on Amazon ECS with Jenkins

Nishath J P — Mon, 27 Jul 2026 04:51:09 +0000

Deploying a container is easy.

Deploying it safely, repeatedly, with security checks and a rollback path is a different challenge.

While learning more about container deployment patterns on AWS, I wanted to build something beyond a basic:

Docker Build → Push Image → Deploy

So, I build a project called DeployGuard, which is a hands-on CI/CD project which combines tools like jenkins, Docker, Trivy and multiple AWS services to implement automated Blue/Green deployment on Amazon ECS.

My goal was not to simply run a application. I wanted to understand what happens when a developer pushes a code and how production traffic reaches to a new container.

Github repo: https://github.com/Nishath06/DeployGuard?utm_source=chatgpt.com

What I Wanted to Build

My target workflow was:

Developer
    │
    ▼
 GitHub
    │
    ▼
 Jenkins
    │
    ├── Run Tests
    │
    ├── Build Docker Image
    │
    └── Scan Image with Trivy
    │
    ▼
 Amazon ECR
    │
    ▼
 Amazon ECS
    │
    ▼
Blue/Green Deployment
    │
    ▼
Application Load Balancer
    │
    ▼
   Users

For monitoring purpose I also wanted the application logs available through AWS CloudWatch thus the deployment success is not only indicated by the application health.

AWS Architecture

The AWS side of DeployGuard uses:

Amazon ECR: to Store container image.
Amazon ECS with Fargate: for running the container.
AWS Application load balancer: for routing traffic.
Target Groups: for blue/green deployments.
Jenkins: for CI/CD workflow.
Trivy: for container vulnerability scanning.

Automating the Workflow with Jenkins

Jenkins was responsible moving application through different stages of the delivery process.

Stages:

Checkout
   ↓
Prepare Build Info
   ↓
Test
   ↓
Docker Build
   ↓
Trivy Scan
   ↓
ECR Login
   ↓
Push ECR
   ↓
Verify ECR Image
   ↓
Deploy to ECS

One thing I wanted was traceability between source code and container images.

During the pipeline, Jenkins retrieves the short Git commit SHA:

git rev-parse --short HEAD

That value can then be used as the Docker image tag.

For example:

deployguard:84015e5

This was much more useful than having every build represented only as latest, because I can identify which source revision produced an image.

Adding Container Security Scanning

Before pushing the application container to deployment workflow, I added Trivy to jenkins.

The pipeline scans the built image for HIGH and CRITICAL vulnerabilities:

trivy image \
    --severity HIGH,CRITICAL \
    --exit-code 0 \
    ${IMAGE}:${GIT_SHA}

For this project, I used --exit-code 0, which meaning vulnerabilities are reported but don't automatically stop the pipeline.

For stricter production pipeline, we could turn the scan into a security quality gate so that unacceptable vulnerabilities prevent the image from reaching production.

For example:

Docker Build
     │
     ▼
Trivy Scan
     │
     ├── Pass ─────► Push to ECR
     │
     └── Fail ─────► Stop Pipeline

This is one of the improvements I plan to make as I continue developing DeployGuard.

Storing Images in Amazon ECR

After testing and scanning, Jenkins authenticates with Amazon ECR and pushes the Docker image.

Now ECS can pull the image from the ECR using roles when creating a new task.

One issue I encountered here taught me an important lesson about container tagging.

During an earlier deployment, ECS reported:

CannotPullContainerError
The service was attempting to retrieve an image tag that wasn't available in the ECR repository.

Fixing the tagging strategy and ensuring the required image existed in ECR resolved the problem.

That experience made the relationship between Jenkins → ECR → ECS task definition much clearer to me.

Why Blue/Green Deployment?

Normal replacement deployment can introduce risk in production

For example

Imagine version 1 is currently running:

Users → Version 1

Version 2 is released, but it contains a problem.

If version 1 has already been replaced, recovering may require another deployment.

Blue/green deployment takes a different approach.

Two environments are available:

BLUE → Existing deployment GREEN → New deployment

The new version can start in the alternate environment before it becomes the production target.

For DeployGuard, I created two target groups:

deployguard-blue deployguard-green

An important concept I learned is that blue doesn't permanently mean production and green doesn't permanently mean staging.

They are deployment slots.

After deployments, their roles can alternate.

Routing Traffic with an Application Load Balancer

The Application Load Balancer provides the public entry point to DeployGuard.

Conceptually:
`
Users
│
▼
Application Load Balancer
│
Production Traffic
│
┌───────┴───────┐
▼ ▼
BLUE TG GREEN TG
│ │
▼ ▼
ECS Tasks ECS Tasks

Watching ECS Perform the Deployment

After all the configurations issues, I could finally see the successful deployments from the ECS console.

In this process I also encountered failed rollbacks.

Some of the issues I had to troubleshoot included:

CannotPullContainerError
incorrect/missing ECR image tags
target group configuration
ALB returning 503 Service Temporarily Unavailable
ECS tasks failing to become available
deployment circuit breaker rollbacks

Eventually the same deployment history started showing:
❌ Rollback failed
❌ Rollback failed
✅ Success
✅ Success

The failures forced me to understand what ECS was actually doing rather than simply following configuration steps until something worked.

Observability with Amazon CloudWatch

A deployment showing "Success" doesn't necessarily tell me everything about the application.

I therefore configured the ECS task to send container logs to Amazon CloudWatch Logs.

The Final Application

After connecting the pipeline and AWS infrastructure, DeployGuard was accessible through the Application Load Balancer.

I designed the UI around the deployment concepts being demonstrated by the project.

It visualizes information such as:

Environment
Application Version
Deployment Slot
Application Health
Git Commit
Build Number
Blue/Green State

The dashboard itself is only the visualization layer.

The actual deployment, task management, target registration and traffic routing happen through the AWS infrastructure behind it.

What Happens After a Code Change?

Putting everything together helped me understand the complete deployment lifecycle:

Developer pushes code ↓ GitHub ↓ Jenkins triggered ↓ Application tests ↓ Docker image built ↓ Trivy vulnerability scan ↓ Image pushed to Amazon ECR ↓ ECS deployment triggered ↓ New ECS/Fargate task starts ↓ Task joins alternate target group ↓ Health validation ↓ Blue/Green deployment proceeds ↓ Application serves traffic ↓ Logs → Amazon CloudWatch

That's considerably more interesting than the docker build and docker run workflow I started with.

Three Things This Project Taught Me

**1. A successful CI pipeline doesn't mean a successful deployment

Health checks are critical to safe deployments
Debugging AWS integrations teaches more than isolated services**

Final Thoughts

DeployGuard started as an experiment to understand blue/green deployments.

It ended up teaching me much more about how CI/CD systems interact with AWS infrastructure.

Instead of learning Amazon ECS, Amazon ECR, ALB, CloudWatch, Docker, Jenkins and container security independently, I had to make them work together as one system.

And when they didn't work together, debugging those failures became part of the learning process.

If you're learning AWS or DevOps, I'd recommend building something where multiple AWS services have to interact rather than stopping after deploying a single container.

You learn a lot when the architecture breaks. 🙂

The complete source code and Jenkins pipeline are available here:

Nishath06 / DeployGuard

DeployGuard Demo App

Purpose

DeployGuard Demo App is a lightweight, production-ready demonstration application engineered specifically for DevOps pipelines incorporating Docker, Jenkins CI/CD, Amazon ECR, and AWS ECS Fargate with Blue/Green deployments.

It demonstrates core SRE & DevOps patterns:

Zero-downtime Blue/Green deployments (traffic routing between BLUE and GREEN slots).
Version visibility and tracking (prominent UI indicators for LinkedIn / portfolio demos).
Automated health check validation (AWS ECS ALB integration).
Rollback simulation via intentional health endpoint degradation.

Architecture

Features

⚡ Lightweight & High-Performance: Built using FastAPI and Uvicorn.
🎨 DevOps SRE Dashboard Aesthetic: Dark theme with slot indicators and completed pipeline stages.
🔄 Live Status Polling: Dynamic UI updates without page reloads.
🐳 Single Docker Container: Packaged in a minimal python:3.12-slim container with native Python Docker HEALTHCHECK.
🧪 100% Test Coverage: Complete unit test suite using pytest.

Environment Variables

The application…

View on GitHub

I'm continuing to improve DeployGuard as I learn more about AWS deployment patterns, security and observability.

If you have suggestions for improving the architecture, I'd be happy to hear them!

AWS 2025 Recap: A Year Where Cloud Became Smarter, Simpler, and More Human

Nishath J P — Wed, 31 Dec 2025 18:35:03 +0000

If 2024 was about scaling cloud faster, 2025 was about making cloud make sense.

AWS didn’t just launch new services this year — it refined how developers, DevOps engineers, and architects actually work. From AI deeply embedding itself into daily workflows to major improvements in serverless, security, and cost optimization, 2025 quietly reshaped AWS into a more intelligent and developer-friendly platform.

Here’s a clean recap of the most important AWS updates and shifts in 2025, explained in a way that actually feels useful.

1. AI Is No Longer a Feature — It’s the Foundation

In 2025, AWS stopped treating AI as a separate “thing” and started baking it into everything.

Key highlights:

Amazon Bedrock matured into a production-ready AI platform, not just a model playground.
Native support for multiple foundation models (Anthropic, Meta, Mistral, Amazon Titan) improved drastically.
Fine-tuning, guardrails, and evaluation tools became easier and cheaper.
AI workloads now integrate smoothly with Lambda, Step Functions, S3, and DynamoDB.

Big shift:

AI on AWS is no longer just for ML engineers. Backend developers, DevOps teams, and even cloud admins are now using AI as part of normal architecture.

2. Amazon Q Became the “Cloud Copilot” We Actually Needed

Amazon Q quietly became one of AWS’s most impactful launches.

In 2025, Q evolved from a chatbot into a context-aware assistant that understands:

Your AWS account
Your architecture
Your logs, metrics, and cost data
Your infrastructure code

What made it powerful:

Natural language troubleshooting for CloudWatch and X-Ray
Security explanations for IAM and GuardDuty findings
Cost optimization suggestions that actually make sense
Code assistance inside IDEs for AWS SDKs and IaC

Reality check:

Amazon Q didn’t replace engineers — it reduced cognitive load. And that’s a win.

3. Serverless Grew Up (Finally)

AWS doubled down on serverless maturity, not just features.

Important improvements:

AWS Lambda cold starts reduced further, especially for Java and .NET
Better VPC networking performance for serverless apps
Step Functions gained more expressive workflows with lower execution cost
EventBridge became more predictable for large-scale event routing

The real win:

You can now build serious production systems entirely serverless without hacks, workarounds, or hidden costs.

Serverless in 2025 feels stable, not experimental.

4. Containers & ECS Quietly Won Another Year

While Kubernetes still dominates headlines, AWS ECS continued winning real workloads.

2025 updates focused on:

Better ECS + ALB integration
Improved auto scaling signals
Lower Fargate networking overhead
Easier blue/green deployments

ECS didn’t try to become Kubernetes.

It focused on doing one thing extremely well: running containers on AWS with minimal effort.

For many teams, ECS + Fargate in 2025 is the lowest-stress container platform available.

5. Security Shifted from Reactive to Preventive

AWS security in 2025 felt less like alerts and more like guidance.

Major improvements:

IAM Access Analyzer became more actionable
GuardDuty findings became clearer and prioritized
Security Hub correlations improved
Default encryption, logging, and isolation got stronger

The biggest change:

AWS started preventing bad architectures instead of just warning about them.

Security became something you design once, not firefight daily.

6. Cost Optimization Became Smarter (and Less Painful)

2025 acknowledged a hard truth: cloud bills were hurting teams.

AWS responded with:

Smarter cost anomaly detection
Better visibility into NAT Gateway, data transfer, and idle resources
Improved Savings Plans recommendations
Clearer breakdowns for serverless and AI workloads

Cost optimization moved from:

“Read a 30-page bill”

to

“Here’s what’s wrong and how to fix it.”

That’s progress.

7. Networking & Architecture Became More Opinionated

AWS in 2025 leaned into best-practice architecture by default.

ALB and NLB usage became more intuitive
VPC design guidance improved
Cross-region and multi-AZ architectures got easier
High availability became the default, not an advanced topic

AWS started nudging users toward well-architected systems, instead of letting bad designs silently fail later.

8. DevOps Felt More Integrated Than Ever

CI/CD, infrastructure, monitoring, and security started feeling like one workflow.

CodePipeline and CodeBuild improved reliability
IaC (CloudFormation, CDK, Terraform) became more consistent
Observability with CloudWatch, OpenTelemetry, and X-Ray improved
Fewer third-party tools were mandatory

In 2025, AWS felt closer to a complete DevOps platform, not just a collection of services.

Final Thoughts: AWS in 2025 Is About Clarity

AWS 2025 wasn’t flashy — and that’s exactly why it mattered.

This year focused on:

Reducing complexity
Embedding intelligence
Improving defaults
Helping engineers make better decisions faster

AWS didn’t try to be trendy.

It tried to be useful.

And honestly? That’s the best kind of update.

If you’re a developer, DevOps engineer, or cloud architect:

2025 was the year AWS stopped asking “What can we build?”

and started asking “How can we make this easier for humans?”

🔐 Advanced IAM for the AWS Solutions Architect – Associate (SAA-C03) Exam

Nishath J P — Thu, 30 Oct 2025 18:00:35 +0000

AWS Organizations

• Global service
• Allows to manage multiple AWS accounts
• The main account is the management account
• Other accounts are member accounts
• Member accounts can only be part of one organization
• Consolidated Billing across all accounts - single payment method
• Pricing benefits from aggregated usage (volume discount for EC2, S3…)
• Shared reserved instances and Savings Plans discounts across accounts
• API is available to automate AWS account creation

Advantages

• Multi Account vs One Account Multi VPC
• Use tagging standards for billing purposes
• Enable CloudTrail on all accounts, send logs to central S3 account
• Send CloudWatch Logs to central logging account
• Establish Cross Account Roles for Admin purposes

Security: Service Control Policies (SCP)
• IAM policies applied to OU or Accounts to restrict Users and Roles
• They do not apply to the management account (full admin power)
• Must have an explicit allow from the root through each OU in the direct path
to the target account (does not allow anything by default – like IAM)

SCP Hierarchy

Management Account
• Can do anything (no SCP apply)
Account A
• Can do anything
• EXCEPT S3 (explicit Deny from
Sandbox OU)
• EXCEPT EC2 (explicit Deny)
Account B & C
• Can do anything
• EXCEPT S3 (explicit Deny from
Sandbox OU)
Account D
• Can access EC2
Prod OU & Account E & F
• Can do anything

SCP strategies

Allowlist : Allows all actions and deny particular ones.
Denylist : Denys all actions and allows particular ones.

AWS Organizations –Tag Policies

• Helps you standardize tags across resources in an AWS Organization
• Ensure consistent tags, audit tagged resources,maintain proper resources categorization, …
• You define tag keys and their allowed values • Helps with AWS Cost Allocation Tags and Attribute-based Access Control
• Prevent any non-compliant tagging operations on specified services and resources (has no effect on resources without tags)
• Generate a report that lists all tagged/non-compliant resources
• Use EventBridge to monitor non-compliant tags

IAM Conditions
aws:SourceIp
restrict the client IP from which the API calls are being made

aws:RequestedRegion
restrict the region the API calls are made to

ec2:ResourceTag
restrict based on tags

aws:MultiFactorAuthPresent
to force MFA

*IAM for S3 *
• s3:ListBucket permission applies to arn:aws:s3:::test
• bucket level permission • s3:GetObject, s3:PutObject, s3:DeleteObject applies to arn:awn:s3:::test/*
• object level permission

Resource Policies & aws:PrincipalOrgID

• aws:PrincipalOrgID can be used in any resource policies to restrict
access to accounts that are member of an AWS Organization

IAM Roles vs Resource Based Policies

• Cross account:
• attaching a resource-based policy to a resource (example: S3 bucket policy)
• OR using a role as a proxy

IAM Roles vs Resource-Based Policies

• When you assume a role (user, application or service), you give up your
original permissions and take the permissions assigned to the role
• When using a resource-based policy, the principal doesn’t have to give up his
permissions
• Example: User in account A needs to scan a DynamoDB table in Account A
and dump it in an S3 bucket in Account B.
• Supported by: Amazon S3 buckets, SNS topics, SQS queues, etc…

Amazon EventBridge – Security

• When a rule runs, it needs permissions on the target
• Resource-based policy: Lambda, SNS, SQS, S3 buckets, API Gateway…
• IAM role: EC2 Auto Scaling, Systems Manager Run Command, ECS task…

IAM Permission Boundaries

• IAM Permission Boundaries are supported for users and roles (not groups)
• Advanced feature to use a managed policy to set the maximum permissions
an IAM entity can get.
Can be used in combinations of
AWS Organizations SCP
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
Use cases
• Delegate responsibilities to non administrators within their permission boundaries, for example create new IAM users
• Allow developers to self-assign policies and manage their own permissions, while making sure they can’t “escalate” their privileges (= make themselves admin)
• Useful to restrict one specific user (instead of a whole account using Organizations & SCP)

IAM Policy Evaluation Logic

AWS IAM Identity Center (successor to AWS Single Sign-On)

• One login (single sign-on) for all your
• AWS accounts in AWS Organizations
• Business cloud applications (e.g., Salesforce, Box, Microsoft 365, …)
• SAML2.0-enabled applications
• EC2 Windows Instances
• Identity providers
• Built-in identity store in IAM Identity Center
• 3rd party: Active Directory (AD), OneLogin, Okta…

AWS IAM Identity Center Fine-grained Permissions and Assignments
• Multi-Account Permissions
• Manage access across AWS accounts in your AWS Organization
• Permission Sets – a collection of one or more IAM Policies assigned to users and groups to define AWS access
• Application Assignments
• SSO access to many SAML 2.0 business applications (Salesforce, Box, Microsoft 365, …)
• Provide required URLs, certificates, and metadata
• Attribute-Based Access Control (ABAC)
• Fine-grained permissions based on users’ attributes stored in IAM Identity Center Identity Store
• Example: cost center, title, locale, …
• Use case: Define permissions once, then modify AWS access by changing the attributes

Microsoft Active Directory (AD)

• Found on any Windows Server with AD Domain Services
• Database of objects: User Accounts, Computers, Printers, File Shares, Security Groups
• Centralized security management, create account, assign permissions
• Objects are organized in trees
• A group of trees is a forest

AWS Directory Services

AWS Managed Microsoft AD
• Create your own AD in AWS, manage users
locally, supports MFA
• Establish “trust” connections with your on- premises AD

AD Connector
• Directory Gateway (proxy) to redirect to on- premises AD, supports MFA
• Users are managed on the on-premises AD

Simple AD
• AD-compatible managed directory on AWS
• Cannot be joined with on-premises AD

IAM Identity Center – Active Directory Setup

• Connect to an AWS Managed Microsoft AD (Directory Service)
• Integration is out of the box
• Connect to a Self-Managed Directory
• Create Two-way Trust Relationship using AWS Managed Microsoft AD
• Create an AD Connector

AWS Control Tower

• Easy way to set up and govern a secure and compliant multi-account AWS environment based on best practices
• AWS Control Tower uses AWS Organizations to create accounts
Benefits:
• Automate the set up of your environment in a few clicks
• Automate ongoing policy management using guardrails
• Detect policy violations and remediate them
• Monitor compliance through an interactive dashboard

AWS Control Tower – Guardrails
• Provides ongoing governance for your Control Tower environment (AWS Accounts)
• Preventive Guardrail – using SCPs (e.g., Restrict Regions across all your accounts)
• Detective Guardrail – using AWS Config (e.g., identify untagged resources)

🧩 Conclusion

Mastering AWS Identity and Access Management (IAM) is one of the most crucial skills for the Solutions Architect – Associate (SAA-C03) exam. Beyond passing the certification, understanding IAM’s depth helps you design secure, scalable, and compliant architectures in real-world AWS environments.

From Organizations and SCPs to Permission Boundaries and IAM Identity Center, each feature plays a role in maintaining the principle of least privilege while supporting flexibility across multi-account setups.

When preparing for the exam, focus not only on memorizing IAM terms but also on how they connect—for example, how SCPs differ from IAM policies, or how ABAC complements tagging strategies.
Practical experience—such as building and testing roles, cross-account access, and SSO configurations—will reinforce these concepts and make your knowledge exam-ready and job-ready.

Keep exploring AWS documentation and hands-on labs to strengthen your foundation, and remember:

“Security in the cloud is not just a checkbox — it’s a mindset.”

If you are preparing for SAA-C03 exam this is for you a complete IAM guide

Nishath J P — Mon, 20 Oct 2025 15:09:04 +0000

🔐 Mastering IAM for the AWS Solutions Architect – Associate (SAA-C03) Exam

Nishath J P ・ Oct 20

#awschallenge #cloud #aws #devops

🔐 Mastering IAM for the AWS Solutions Architect – Associate (SAA-C03) Exam

Nishath J P — Mon, 20 Oct 2025 15:07:19 +0000

If you’re preparing for the AWS Solutions Architect – Associate (SAA-C03) exam, then Identity and Access Management (IAM) is one topic you can’t afford to skip.

Every single AWS service relies on IAM for authentication and authorization, making it a core part of almost every exam question.

In this post, I’ll break down IAM concepts, best practices, and common exam scenarios so you can confidently answer any IAM-related question that appears on your SAA-C03 exam. This blog only cover theory part but you also need to practice.🚀

IAM: Users & Groups

IAM = Identity and Access Management, It's a Global service
Root account is created by default, Which shouldn’t be used or shared
Users are people within your organization, and can be grouped
Note : Groups only contain users, not other groups
Users don’t have to belong to a single group, and user can belong to multiple groups

IAM: Permissions

The permissions of the users are defined as Policies
Policies is JSON document
Users or Groups can be assigned to a policies
In AWS you apply the least privilege principle: don’t give more permissions than a user needs
Policy can be inherited from the group which user belongs
We can also set a password policy on how the password must be for the user

example policy
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Allow", "Action": "elasticloadbalancing:Describe*" , "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudwatch:ListMetrics", "cloudwatch:GetMetricStatistics", "cloudwatch:Describe*" ], "Resource": "*" }
IAM Policies Structure
Consists of

Version: policy language version, always include “2012-10-17”
Id: an identifier for the policy (optional) • Statement: one or more individual statements (required)
Statements consists of • Sid: an identifier for the statement (optional) - Effect: whether the statement allows or denies access (Allow, Deny)
Principal: account/user/role to which this policy applied to
Action: list of actions this policy allows or denies • Resource: list of resources to which the actions applied to
Condition: conditions for when this policy is in effect (optional)

Multi Factor Authentication - MFA

Users have access to your account and can possibly change configurations or delete resources in your AWS account
You want to protect your Root Accounts and IAM users
MFA = password you know + security device you own
Main benefit of MFA: if a password is stolen or hacked, the account is not compromised

MFA devices options in AWS

Virtual MFA device
Universal 2nd Factor (U2F) Security Key
Hardware Key Fob MFA Device
Hardware Key Fob MFA Device for AWS GovCloud (US)

How can users access AWS ?

To access AWS, you have three options:
AWS Management Console (protected by password + MFA)
AWS Command Line Interface (CLI): protected by access keys
AWS Software Developer Kit (SDK) - for code: protected by access keys
Access Keys are generated through the AWS Console
Users manage their own access keys
Access Keys are secret, just like a password. Don’t share them
Access Key ID ~= username
Secret Access Key ~= password

What’s the AWS CLI?

A tool that enables you to interact with AWS services using commands in your command-line shell
Direct access to the public APIs of AWS services
You can develop scripts to manage your resources
It’s open-source https://github.com/aws/aws-cli
Alternative to using AWS Management Console

What’s the AWS SDK?

AWS Software Development Kit (AWS SDK)
Language-specific APIs (set of libraries)
Enables you to access and manage AWS services programmatically
Embedded within your application
Supports
SDKs (JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++)
Mobile SDKs (Android, iOS, …)
IoT Device SDKs (Embedded C, Arduino, …)
Example: AWS CLI is built on AWS SDK for Python

IAM Roles for Services

Some AWS service will need to perform actions on your behalf
To do so, we will assign permissions to AWS services with IAM Roles Common roles:
EC2 Instance Roles
Lambda Function Roles
Roles for CloudFormation

IAM Security Tools

IAM Credentials Report (account-level)

A report that lists all your account's users and the status of their various credentials IAM Access Advisor (user-level)
Access advisor shows the service permissions granted to a user and when those services were last accessed.
You can use this information to revise your policies

IAM Guidelines & Best Practices

Don’t use the root account except for AWS account setup
One physical user = One AWS user
Assign users to groups and assign permissions to groups
Create a strong password policy
Use and enforce the use of Multi Factor Authentication (MFA)
Create and use Roles for giving permissions to AWS services
Use Access Keys for Programmatic Access (CLI / SDK)
Audit permissions of your account using IAM Credentials Report & IAM Access Advisor
Never share IAM users & Access Keys

Would you like me to make a Part 2 version — something like “Advanced IAM Concepts for SAA-C03 (Permission Boundaries, SCPs & Federation)” — to continue this as a blog series?

[Boost]

Nishath J P — Tue, 14 Oct 2025 06:37:27 +0000

AWS September 2025 Recap — AI Agents, Managed Compute, and Cloud Sovereignty Take Center Stage

Nishath J P ・ Oct 13

#ai #aws #news

AWS September 2025 Recap — AI Agents, Managed Compute, and Cloud Sovereignty Take Center Stage

Nishath J P — Mon, 13 Oct 2025 18:01:15 +0000

A Quick Glance at the Month

Agentic AI received a significant boost with fresh releases to Amazon Bedrock AgentCore as well as new entrant Strands Agents.

Containers were made easier to handle with the release of ECS Managed Instances.

☁️ Storage & Networking received some valuable new features — including IPv6 within Control Tower, along with new features within S3.

Sovereign Cloud & compliance took the spotlight with a massive AWS + SAP collaboration in Europe.

Community & developer programs were extended worldwide with new hackathons, AWS Lofts, and Summits.

Let's go deeper 👇

🤖 The Agentic Age of AI: AWS Raises the Bar

AWS interest in AI agents — self-contained systems that can think, reason, and take action independently — was front and center this month.

🧵 Threads Agents Hit 1 Million Downloads

The open-source Strands Agents SDK exceeded the 1 million download barrier three months after the debut of the preview version.

It now includes:

Multi-agent cooperation
Improved A2A (agent-to-agent) procedures
Simplified integration with AgentCore

This surge shows how quickly developers are experimenting with AWS’s ecosystem for agentic AI — building intelligent assistants, workflow bots, and enterprise-grade automation systems.

Go to the official AWS blog article

🧩 AgentCore Goes Enterprise

The Amazon Bedrock AgentCore also had some real upgrades:

✅ VPC connectivity & PrivateLink support

✅ Increased governance with resource tagging

✅ Integration of CloudFormation with IaC (Infrastructure as Code)

These enhancements enable enterprises to easily deploy secure, scalable AI agents that remain compliant and auditable.

All the latest news

🌍 World AI Agent Hackathon

To encourage innovation, AWS launched a Global AI Agent Hackathon where devs build agents with Strands and Bedrock — with prizes, mentorship, and AWS credits on the line.

It seems that AWS wishes to spark a community around agent development the same way Hugging Face sparked one around models.

🐳 Enhancing Containers with Amazon ECS Managed Instances

Containers were given a big usability upgrade with the introduction of Amazon ECS Managed Instances.

This feature lets you:

Run ECS containers on EC2-like environments
Do away with the trouble of provisioning, patching, or node scaling
Choose default (cost-optimized), or customer-defined instance configurations

It's essentially the sweet spot between EC2 control and Fargate simplicity — perfect for teams that want flexibility but with less ops overhead.

Read the message

🧠 Storage & Networking: S3 und IPv6 werden schwärmerisch

September saw some slight but notable infrastructural enhancements.

Amazon S3 Enhancements

Bulk object selection for S3 Batch Operations
Conditional Deletes for General-Purpose Buckets
Larger scanning file size capacity of the archives
See S3 tables preview in the console

These characteristics facilitate data operation in a smoother and efficient manner — especially for teams dealing with enormous object collections.

🌐 IPv6 Support Added to AWS Control Tower

AWS Control Tower is IPv6 enabled, allowing easy management of dual-stack and powering new networking topologies within accounts.

And yes, AWS also made new Asia Pacific (New Zealand) regions available — yet another steady expansion around the world.

🇪🇺 Cloud Sovereignty: SAP und AWS kommen in Europa zusammen

Perhaps the biggest cloud news this month — AWS and SAP made an announcement about partnering to bring SAP's Sovereign Cloud capabilities to the AWS European Sovereign Cloud.

The deal involves a €7.8 billion investment to allow the public sector and highly regulated industries to benefit from data residency alongside data sovereignty compliance.

This alliance is yet another indication that AWS is very committed to localized control along with compliance — something that has gained momentum across the globe.

Full announcement on SAP Newsroom

🎥 Media & Entertainment: Shining at IBC2025 with AWS

At IBC 2025 (Amsterdam, September 12–15), AWS showed how media workflows are being transformed with generative AI.

A prominent demo saw Reuters collaborate with AWS to show off a next-gen news distribution platform running on:

Amazon S3
AWS MediaConvert
Step Functions
AI-driven metadata tagging

This kind of end-to-end automation can redefine the manner in which broadcasters generate and distribute video.

👩‍💻 Developer Community Highlights

Gen AI Lofts & Conferences

AWS continued to expand the Gen AI Loft sessions — free, hands-on experiences where one could experiment with AWS's AI products in real time.

AWS Summit Los Angeles 2025 brought together thousands of builders along with keynotes, training, and product previews.

☁️ Cloud Club & Hack

AWS continued to expand its Cloud Club Captain program — supporting student leaders and area developer groups.

Along with the continuing hackathons, it becomes obvious that AWS is making significant investment in ground-level developer involvement.

🧭 Key Points — The Bottom Line

These are what generated most interest this month:

Agentic AI is no hype — it's the next big frontier in AWS.

With Strands Agents and AgentCore, Amazon Web Services is creating the plumbing of smart, self-contained systems.
Containers just became simpler to deal with.

ECS Managed Instances are a lifesaver for teams balancing cost control and convenience.
The sovereign cloud is here to stay.

The SAP + AWS alliance demonstrates that data control and compliance will be the core of enterprise cloud strategies.
Developer experience remains front of mind.

From Lofts to Hackathons, AWS is making sure the ecosystem stays dynamic, inclusive, and community-focused.

🔮 Q4 2025 Things to Watch

With the year coming to a close soon, some things to look out for are:

AWS re:Invent 2025 — Huge announcements will be coming around AI, compute, and automation.
Potential public release of "Quick Suite", the speculated internal workspace of AWS's AI.
Expansion of the Sovereign Cloud regions beyond Europe.
Even more "managed but flexible" compute layers, like ECS Managed Instances.
Deeper integration of AI capabilities into regular day-to-day AWS services.

🏁 Final Thoughts

AWS is obviously in acceleration mode.

The drive to quicker rollouts, AI-first infrastructure, and worldwide compliance is the rising cloud space competitiveness.

That equates to additional equipment, automation, and — most important of all — possibilities to be different, to innovate.

If you happen to be working with agentic AI, managed containers, or self-sovereign cloud deployments, there were hints released this month on where exactly AWS is heading next.

Want Some tips to pass your AWS Solutions Architect Exam Check this Blog

Nishath J P — Sun, 05 Oct 2025 14:11:33 +0000

How I Passed the AWS Solutions Architect Associate (SAA-C03) Exam with 863 Marks

Nishath J P ・ Oct 1

#awschallenge #cloud #devops #beginners

Want Some tips to pass your AWS Solutions Architect Exam read this Blog

Nishath J P — Sun, 05 Oct 2025 14:10:38 +0000

How I Passed the AWS Solutions Architect Associate (SAA-C03) Exam with 863 Marks

Nishath J P ・ Oct 1

#awschallenge #cloud #devops #beginners

How I Passed the AWS Solutions Architect Associate (SAA-C03) Exam with 863 Marks

Nishath J P — Wed, 01 Oct 2025 16:31:58 +0000

On September 29, 2025, I cleared my AWS Certified Solutions Architect – Associate (SAA-C03) exam with the score of 863/1000. This milestone is special for me, because just a few months ago I knew very little about AWS like the full form Amazon web services and what is s3.
To my knowledge at that time I though S3 is just like google drive.

From that point with consistent effort, the right resources, and a structured approach, I was able to crack Solutions Architect Associate exam. In this blog, I’ll share my journey, preparation strategy, and key takeaways.

Courses you need

First of all you must need a basic knowledge to on AWS to start preparing for this exam.

I started preparing for AWS Certified Cloud Practitioner at the start of July 1st week 2025.
For that I took [NEW] Ultimate AWS Certified Cloud Practitioner CLF-C02 2025 course from Udemy by Stephane Maarek. The best course to build your foundations it also includes a full length practice test you can use it to test your knowledge.
It took me about 10 days to complete it.

Note - If you already have good foundational knowledge then skip this part.

Then its time to prepare for the SSA-CO3 exam with Ultimate AWS Certified Solutions Architect Associate 2025 course on Udemy by Stephane Maarek.
This one course will give you enough knowledge to take practice tests the course it self has a practice use it to test your knowledge.

This course also includes a study material which he uses to teach. Go through the pdf 2 to 3 times. Take notes and understand the concepts deeply.

Identify your weak areas and do research on it.
Use Chatgpt, AWS whitepapers, Youtube etc... resources.

After you again some confidence get a Udemy personal subscription plan which give you access to all the courses in it.

Practice test

Now comes the hard part you must start taking practice test from

Stephane Maarek
Jon Bonso and
Neal Davis

each one has a practice test of 6 which means total 18.
Plus each of them has their own course which also have one practice test So, total of 21 test.

Try to take them all.

I took them all because this is my first AWS exam and it is Associate level which made me bit nervous about the actual exam.

First take Stephane Maarek practice test which will make you recall all the concepts but it does not resemble actual exam but good to have it.

After taking carefully review the answers and mistake.

If you are good enough to get above 80% in first attempt in all the 6 test.
_If you didn't make it no problem reviews the answer and retake one more time from the oldest test you took. _

Note- Don't take more than two attempts.

Then go for Jon Bonso and Neal Davis practice test take alternatively both highly resemble actual exam.

Might be harder for some if you feel that way review the answers and for more details you can use study material from Neal Davis course he provides two study material.

Full length Notes
Exam Cramp Notes

Both are highly useful Exam Cramp is a shorter version of notes high recommended for revision purpose only not for studying.

Now also try to take 80% or above. Most of the actual exam questions will be like Neal Davis and some will be like Jon Bonso practice test.
Try to complete under 1:30 hr time

But don't memorize the questions try to understand because AWS has over 1 million question sets.

So, understanding is the crucial thing here.

Take it Slowly it took me more than 1 and a half months.

Before the Exam Day

A couple of days before the exam don't take any practice test if you want there is a official practice test from AWS which has around 20 question that is enough don't take too much.

Just go through the mistakes you made in the practice test figure out your weak point try to gain knowledge on it go through the study material take it easy, sleep well.

Clean your room and table for the exam. And be prepared.

On the exam day

You might feel nervous it is normal I also felt that way.
So, take a Walk, meditate and relax.

The exam will be easier than the practice test but you should take the practice test seriously.

Get a chewing gum you can use those in exam but no food, beverages or breaks for restroom.

Take a government Id with you in the exam.

Spend a good amount of time to read each question take 1 to 2 mins per question if you can't find the answer flag it and review it later. Don't sit on single question for long time.

> Go by elimination method eliminate the options that are your are sure incorrect and choose the option which makes more sense to you.

If you finish the exam early review the questions again.

_After finishing you will receive the email about passing mostly with in 24hr to 5days.
But I received in 8hrs.
_

ALL the Best for you exams it is not impossible but need some hard work. That's it, once again ALL the best.

Want to know what AWS bought us on August 2025? A quick recap 👇

Nishath J P — Mon, 08 Sep 2025 15:15:55 +0000

🚀 AWS August 2025 Recap: AI Guardrails, VMware on AWS, Marketplace in India & Prime Day Scale

Nishath J P ・ Sep 6

#ai #aws #awschallenge #cloud