Forem: Imoh Etuk

AWS Kiro: Agentic Coding and the Rise of Spec-Driven AI Development

Imoh Etuk — Sat, 03 Jan 2026 00:23:10 +0000

Modern software development is no longer about writing code faster. It is about building the right systems with clarity, governance, and scale in mind.

AWS Kiro represents AWS’s move beyond traditional AI coding assistants into a full-fledged agentic AI IDE designed to take developers from idea to production-ready implementation using structured, spec-driven workflows. It is a full Stack Software Development with Spec Driven AI

From Coding Assistants to Agentic Development

Most AI tools today are reactive. They respond to prompts but do not plan, reason, or own outcomes.

Agentic coding enables AI to decompose complex problems, generate structured plans, produce multiple artifacts, and iterate collaboratively with developers.

Built on Amazon Bedrock

Kiro is powered by Amazon Bedrock, AWS’s managed service for building generative AI applications using foundation models from Amazon and third-party providers.

This ensures security, compliance, and production readiness.

Conversational Development

Kiro enables natural language conversations directly about your codebase, allowing developers to understand, debug, and refactor complex systems with context awareness.

Building Features End-to-End

From a single prompt, Kiro can generate design documents, data flow diagrams, code, and tests, while keeping the developer in full control.

Spec-Driven Coding

Specifications act as formal contracts that eliminate ambiguity and guide implementation, testing, and documentation.

Agent Hooks

Agent hooks automate routine engineering tasks by responding to file and workspace events.

Steering Files

Steering files encode project conventions so Kiro consistently follows established standards.

Privacy and Security

Kiro supports enterprise-grade security, including customer-managed encryption keys and controlled data usage.

Why AWS Kiro Matters

Kiro represents a shift from assistive AI to agentic, production-ready software engineering.

Final Thoughts

AWS Kiro is not just another AI IDE. It is a redefinition of how software is designed, built, and governed in the age of AI.

Understanding the Shared Responsibility Model in AWS

Imoh Etuk — Tue, 10 May 2022 14:53:07 +0000

In this post, I will be talking about Understanding the Shared Responsibility Model in AWS. This is otherwise known as "YOUR RESPONSIBILITY" vs "AWS RESPONSIBILITY". If you're just about getting started with the AWS Cloud for your business or you're planning to run a test app on AWS Cloud as a developer, it is very important that you understand the shared responsibility model that forms the bedrock of the security and compliance of operation activities in AWS Cloud so as to have a smooth experience.

If you need to learn about the steps you can take to secure an AWS EC2 Instance in AWS, read this

Overview

As a customer, you are responsible for the security in the cloud. So whatever you use, however you configure it, it is completely your responsibility to secure them. These includes your data, operating system, networking environment, and firewall configurations etc. While on the hand, AWS is entirely responsible for the security of the cloud. So all the infrastructure, hardware, software, and their own internal security are purely the responsibility of AWS to secure.

When you use AWS Cloud, you're agreeing to the Acceptable Use Policy which can be found right here. What this means is when you're using the AWS Cloud, it is obvious that you cannot do any illegal, harmful or offensive use of content, security violations, network abuse and e-mail or other informational abuse.

The diagram below gives us some good examples of where the line is of who is responsible for what.

Image by: AWS

As you can see from the diagram above, at the bottom side of it we have the Regions, Availability Zones and Edge Locations. These are known as the Global Infrastructure in AWS Cloud. Right above the items (Global Infrastructure), we have Compute,Storage,Database and Networking. These are the physical servers and the software layers that runs on them. For instance, the compute server in the AWS Datacenter runs an Operating System. Now, it is not your responsibility to manage these servers but that of AWS. Similarly, the storage system also runs some kind of software and they have physical disk and networking configurations and all that is taking care of by the AWS.

Furthermore, for database, it depends on the kind of database. In this case, for instance, DynamoDB is a database and you are responsible for provisioning a table on it and then you're also responsible for the data you store on the table but the underlying database and the hardware that runs on it are taking care of by the AWS.

Networking

Then there is networking in which we have the physical network equipment, and then the routing and switching software that sits on top of them. This is run by AWS. If you move to the top ladder of the diagram as a customer you're responsible for the networking traffic rotation, how you encrypt your data and make sure it is going to the right place for your route tables and so on. You're also responsible for the configuration of network firewalls such as using security groups and Network Access Control List (NACL) are all part of your responsibilities as a customer.

Data Encryption

Server-Side-Encryption (SSE) of your data. For instance, encrypting your data on Amazon S3 is your responsibility. So all forms of encryption are your responsibility. And then you got the Client-Side-Data Encryption as well that's encrypting data that can be brought into the AWS Cloud yourself.

Operating System

For the Operating system, if you're running a Linux, Windows or macOS based EC2 instance you need to manage the security, patching of the guest OS, and update the application that runs on it by yourself. As mentioned before, for the networking and firewall configurations if you're running a firewall on your EC2 instance or you're using security groups and access control list it is your responsibility as a customer to ensure they are well implemented.

Platform, Applications and Identity and Access Management

Moving up another layer in the diagram, we have Platform, Applications and Identity and Access Management. So here we're looking at things like the applications that you install on your system and also the authentication and authorization system, user groups, roles and policies are the customer's responsibility.

Finally, from the diagram, the actual data itself (known as the Customer data) that you store in the AWS cloud is solely what you're responsible for as the customer.

In conclusion, the AWS Shared Responsivity Model defines what you as an AWS customer or a user are responsible for and what AWS are also responsible for and it is in relation to security and compliance. Remember, that AWS is responsible for the security of the cloud that means protecting the infrastructure that runs the services offered in the cloud and these includes hardware, software, networking and facilities that runs AWS cloud services. On the other hand, customers are responsible for security in the cloud and these includes EC2, network access control lists (NACLs), Security groups, Operating system patches and updates, IAM users access management, and client and server-side data encryption.

For further reading, checkout the following links:

How to grant public access to S3 Bucket using Policy

Imoh Etuk — Wed, 06 Apr 2022 11:09:48 +0000

Did you know that by default AWS S3 Bucket is not publicly accessible? The answer is "YES". So if the public access is blocked by default, adding a policy that grant public access to your bucket is very necessary.

Amazon S3 buckets policy offers fine-grained access control and makes it possible to offer cross-account access.

In this post, you will learn everything about AWS S3 buckets and S3 storage service in general. If you wish to learn about this, click on this link to read the post which was previously published on TechDireactArchive blog.

Read and share your experience.

Happy reading 👌

How to Secure Amazon EC2 Instances

Imoh Etuk — Tue, 15 Mar 2022 15:48:32 +0000

In this write-up, I will introduce you to the overview of cloud security, what Amazon EC2 Instance is and how to secure Instances of EC2.

Overview of Cloud Security

The security of cloud resources is of utmost importance as more and more organizations migrate their on-premises resources to the cloud, either through the lift-n-shift strategy or a one-time migration process. Many of the same security controls, technologies, policies, and processes used to protect physical data centers, networks, and compute environments are delivered as a service to protect your cloud data.
Confidentiality, integrity, and availability are the three essential qualities of secure cloud services. Confidentiality refers to the ability to keep information hidden from those who should not have it. Integrity refers to the ability of systems to function as intended and to deliver results that are neither unexpected nor deceptive. While Availability refers to the uptime of cloud infrastructure and cloud-based services, as well as the prevention of Denial-of-Service (DoS) attacks.

What is an Amazon EC2 Instance?

An Amazon EC2 Instance is a virtual server Amazon's Elastic Compute Cloud (EC2) for running applications on the Amazon Web Services (AWS) infrastructure . AWS is a robust and ever-evolving cloud computing platform, while EC2 is a service that allows businesses to run application programs in a computing environment. It can be used to create an almost infinite number of virtual machines (VMs). To meet the needs of its customers, Amazon offers a variety of instances with varying configurations of CPU, memory, storage, and networking resources. Each type is available in a variety of sizes to meet the needs of different workloads.

AWS customers can launch and fully control virtual machines in the cloud using the Amazon Elastic Compute Cloud (Amazon EC2). Amazon EC2 offers several instance types to serve various operating systems, each with its own set of security capabilities and requirements. Each Instance of EC2 is launched from Amazon Machine Image.

An Amazon Machine Image (AMI) contains all of the information needed to launch an instance. When you launch an instance, you must specify an AMI. When you need multiple instances with the same configuration, you can launch them all from a single AMI. When you need instances with different configurations, you can launch them using different AMIs.

After setting the stage with this discussion, here are four critical tips to help you ensure that your EC2 instances are properly secured.

1. Secure your VPC

Amazon Virtual Private Cloud (Amazon VPC) is an Amazon Web Services feature that allows you to define a logically isolated virtual network in which to provision your AWS resources. IP addresses, subnets, route tables, gateways, network interfaces, endpoints, and other components make up a VPC.

VPC serves as the underlying physical host to EC2 Instance and if the host that runs your EC2 instance is compromised in some way, your instance may be compromised as well.

One way to ensure that your VPC is secured is to begin from scratch by creating a new Virtual Private Cloud. Although AWS provides a default Virtual Private Cloud in each region of your AWS account, it is preferable if you do not use the default VPC and instead create your own new VPCs. The reason for this is that the default VPC's security configuration is basically open because subnets in the de facto VPC are associated with your main routing table, which does not place any restrictions on inbound or outbound traffic. So, from the standpoint of securing your AWS resources (EC2 in particular), it's always best to create new VPCs and then defines custom route tables for each VPC as all other resources in your AWS account depend on it to communicate and exchange information.

2. Know your security groups

AWS offers two types of virtual firewalls that you can use to control the inbound and outbound flow of network traffic in your environment. Network access control lists (NACLs) and security groups are the two types of firewalls. While NACLs are important for securing communication with VPCs because they control access to subnets in your cloud environment, security groups are important for securing communication with EC2 instances.

To secure your EC2 instances, you must first ensure that you have a thorough understanding of how security groups work. Amazon has a good description of how to use security groups to secure inbound traffic for Linux instances, and by working through the scenario they present, you can gain a good understanding of how to use security groups to protect other types of instances. However, the fundamental principles are straightforward: assign one or more security groups to your instance, then add rules to each security group to allow specific types of traffic to your instance. Keep in mind the cardinal rules of access control, which are: least privilege and least access.

3. Make Use of IAM roles

When setting up your AWS environment for the first time, you are given security credentials that allow you to access all of your AWS resources, including EC2. Use these default AWS credentials for granting users, applications, or services access to your instances at your own risk! Instead, use AWS Identity and Access Management (IAM) to limit how much access users, applications, and services have to your instances and other resources like storage. IAM is an AWS feature that allows you to create users and groups and assign them unique security credentials. IAM can also be used to create JSON-format policies for performing various tasks on instances via the EC2 APIs.

Even more importantly for managing instance security, IAM allows you to create roles. IAM roles enable the management of AWS credentials for applications running on EC2 instances. This is significant because API calls made by applications must be signed with valid AWS credentials. Typically, you will create an IAM role and assign it to your EC2 instance. The IAM role has been configured to provide secure access to another AWS resource, such as an S3 bucket, and the role's required permissions are defined by an IAM policy you created. After that, the instance is launched in EC2, and the IAM role generates temporary credentials for the instance to be used in order to access the bucket. The benefit of using IAM roles in this manner is that root credentials stored in the instance are not used to access the bucket; instead, temporary credentials are used, which is more secure because root credentials are not exposed.

4. Protect your EC2 Instances Against Malware

Apart from other points stated above, protecting your EC2 instances from malware infection is an important part of the task of securing your instances. Many of the same practices that you use to harden the physical servers in your server room or datacenter can be applied here. This means, that you should:

Make sure that any applications or other executable code you install on your instance are from a reputable source.
If you're using AMIs, make sure the Amazon Machine Image (AMI) from which you launch your instance is also from a trusted source.
Ensure that your instance's guest OS and installed applications are fully patched and that newly released patches are applied in a timely manner.
Ensure that trusted anti-malware software is installed and running on the guest OS and that the software's signatures are updated on a regular basis.
Ensure that the guest operating system on your instance is properly secured in line with the operating system's standard hardening procedures

Summary

In all you do remember the shared responsibility model i.e. the Security of the cloud and the Security in the cloud. Do your path to ensure that you control network access to your instances, manage the login credentials used to connect to your instances, manage the guest operating system and software installed on it, along with updates and security patches and configure the IAM roles attached to the instance, as well as the permissions linked with those roles, and watch AWS takes care of the security of the cloud for you. Cheers!🙌🙌

Serverless, the future of computing

Imoh Etuk — Sat, 19 Sep 2020 07:08:24 +0000

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles from community members and cloud advocates are published every week from Monday to Thursday through September.

Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/

Introduction

The ability to handle data to take certain actions and offer services is paramount in our present reality in the computing world.

Over the years, companies have been developing applications and deploying them on servers -on-premises. What this means is that companies will have to figure out how many servers, storage, and database power they need ahead of time, and deploying all of the hardware and software it takes to run the application. Suppose you didn’t want to deal with all of that and were looking for a new model that handled the entire underlying infrastructure deployment for you, serverless is the answer.

Serverless computing is embraced slowly but surely getting the attention of web developers. This type of programming is completely changing the way applications are constructed, distributed, and run. You can build and use apps without thinking about servers.

What is Serverless Computing?
Serverless is simply a model where Cloud providers help in running and managing your server, thus, enabling you to focus on the important part of your application.

“Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It can be a form of utility computing” (Wikipedia).

As you can see here, despite its name, the servers still exist. The model doesn’t remove servers; the software only exists in the public cloud.

You can build them for almost any type of backend service or application. What it does is that it eliminates some tasks such as maintenance of operating system, capacity and cluster provisioning, and patching.

There are two types of serverless architecture:

Backend as a Service (BaaS)
Function as a Service (FaaS)

Serverless has different names according to each public cloud provider. Of course, when it comes to serverless offerings, there are “Big Three” which rule the market:

In Amazon Web Service (AWS), it is known as Lambda
In Google Cloud, it is known as Cloud Functions
In Microsoft Azure, it is known as Azure Function

Let’s look at Backend-as-a-Service (BaaS) in details
Similar to FaaS, Backend-as-a-Service (or BaaS) is a type of serverless technology. Some will contend that BaaS takes it a step further as a NoOps offering. NoOps essentially refers to infrastructure that has been automated to the point that in-house developers have no hand in its operation.

Either way here is an easy way to look at BaaS: imagine your organization is developing a mobile app to connect employees to important information on the go. You might develop the basic application framework in-house, and outsource the functionality. This includes backend processes like access to cloud storage, syncing, and social collaboration.
An organization’s ability to offer backend services that link a mobile application to the cloud is referred to as BaaS.

Now, Function-as-a-Service (FaaS)

In the realm of pre-packaged services, Function-as-a-Service is also sometimes known as Framework-as-a-Service or FaaS, falls in between Software-as-a-Service and Platform-as-a-Service.

Think of FaaS as a ready-to-implement framework that can be easily directed to the needs of an organization. For further clarification, SaaS is ready to use out of the box while FaaS is not. However, FaaS does not require the resources to implement that you would need if you were using PaaS.

FaaS can be delivered in customizable templates, for instance, by industry vertical. FaaS uses containers to prime for the rapid deployment of applications on all platforms. For instance, developers can stack containers for scalability or write one container for iOS development and another for desktop applications. Consumers purchase FaaS from third-party vendors who handle server management. They are then charged for actual runtimes instead of pre-allocated units.

Benefits of Serverless Computing

So, how important is Serverless to businesses and people in general?

The benefits/advantages of Serverless cannot be overlooked as it allows organizations and individuals to do less on-premises cron jobs thereby increasing efficiency and scalability.

The first and foremost advantage is of not needing any hardware or physical space. When you do not need any infrastructure, you save more money (Capital Expenditure; CAPEX)
Scalability at its peak - You can scale up or down your server space as per your requirements.
High availability is another factor that makes having your server in the cloud an ideal solution.
By paying for what you consume, you enjoy the flexibility of Operational Expenditure (OPEX) because you’re not paying for the server unit but for the consumption rate.
Developers need to use code constructs that are within the serverless context, so they have to produce code that meets security compliance set by the public cloud providers.

Why is Serverless the future of cloud computing?
Serverless is the new paradigm shift in cloud computing where you run your applications and services without independently provisioning or managing the servers, hence, serverless.

With the serverless services, cloud providers such as Amazon Web Services, Microsoft Azure, Google Cloud, and Oracle Cloud Infrastructure (OCI) are finally delivering on the true promise of the cloud — limitless capacity and automatic scaling with no configurations or set up to manage.

In this model, cloud providers take full responsibility for operating and managing the infrastructure, and in return helping businesses focus on their high valued applications.

The cloud providers offer serverless compute time by providing “Function as a Service” (FaaS). With FaaS, every time your code is invoked, the FaaS provider runs your code on a server that is provisioned, optimized, and patched with the latest updates.

Let’s get very Specific, Why Serverless?
Whether you are a Developer, DevOps, or Product owner you want to take advantage of this modern-day technology serverless for building and architecting your next cloud application.

Developer: Just write code

Write code and deploy your service without ever having to think about the number of machines to provision.
High availability and horizontal scaling is out of the box with no additional architectural or configuration changes.
Polyglots choose the optimal language for the problem at hand — Go, Javascript (NodeJS), Python, Java, C# where you don’t have to worry about installing runtimes and dependencies.
The cost of operating a non-prod environment is very low as you never pay for idle time. Combined with the scale on-demand, this should enable developers to rapidly iterate on their new changes.

DevOps Engineer: No administration at all

No patching/downtime notices — Imagine being 100% compliant with meltdown/spectre while everyone is busy taking servers down, and patching them.
No more provisioning of resources based on current, peak and anticipated loads. No midnight pagers to handle surge of traffic.
Run your scheduled cron jobs without the overhead of standing up or maintaining the one-off machines.

Product Owner: Offers agility and improved productivity at reduced costs

FaaS has utility pricing, you pay only when your resource is used and not when resources are provisioned. This could mean significant savings for your business as you will no longer pay for idle resources or orphaned VMs and unused Containers.
Developers and DevOps have fewer things to worry about leading to accelerated delivery.
Your application is ready to scale on the first day of deployment.

Time to go Serverless!
Serverless computing is the way of the present and future for many types of simple applications. It’s an ideal approach for some organizations because it offers the following benefits:

Efficient use of resources
Rapid deployment
Cost-effective solutions
Focus on coding
Familiar programming environment and languages supported
Increased scalability

For these reasons, it’s easy to see why many companies are keying-in. At the same time, it is pertinent to understand that serverless architecture does have drawbacks that need to be considered before making any changes to your business model.

When you use a third party API the following concerns emerge:

Vendor control issues: Developers give up control, especially in the case of BaaS systems.
Security concerns: These arise as a result of leaving security in the hands of the public cloud providers.
Contract lock-in: This occurs when consumers are unable to break contracts with their vendors.
Dependent relationship: Consumers are dependent on vendors for debugging and monitoring.
Limitations: Limits exist on processes to sidestep the pitfalls of overcomplicated architecture.
Response Latency: Because consumers are only billed for runtime, code is powered down between requests. Response times can vary as a result.

Due to the above-mentioned challenges, serverless computing is often not typically ideal for high-performing, complex application builds.

Conclusion
The future of cloud computing is serverless. In the coming days, changes will continue to evolve where there will be more architectural patterns to support more types of workloads.

Companies that have adopted serverless are seeing a significant increase in agility, cost savings as well as operational benefits.

If your organization is already in the cloud, it is in your best interest to start identifying and piloting workloads to leverage serverless. For organizations that are yet to make it to the cloud, this could be your opportunity to ‘lift-n-shift’ your applications, and its associated data to a cloud platform and re-architect your on-premise solutions to leverage serverless.