DEV Community: Nadtakan Futhoem (Nad)

What does AWS Certification mean to me as a long-time developer?

Nadtakan Futhoem (Nad) — Fri, 26 Jun 2026 17:52:39 +0000

After six months of studying, the day had finally arrived.

On a Tuesday morning at 7:45 AM, I started the check-in process for my AWS Certified Solutions Architect – Associate exam. I took the required photos, completed the identity verification, and spoke with the proctor before beginning the exam.

For the next two and a half hours, I worked through each question one by one. Some answers came quickly, while others I flagged to revisit later. As the timer counted down, I focused on staying calm and making the best decision I could for each question.

Then the five-minute warning appeared.

"Okay, time to wrap this up."

I reviewed the questions I had flagged, made my final decisions, and clicked Submit.

With the exam complete, I closed my laptop, took a deep breath, and went back to work, knowing I'd done my best.

A little while later, I glanced at my Outlook inbox and noticed an email with the subject:

"Congratulations! You've received..."

I paused for a second, wondering what it was about.

I opened the email, and there it was:

"Congratulations! You've earned the AWS Certified Solutions Architect – Associate badge."

For a moment, I just smiled.

My first thought was:

"Oh... really? 😆 I couldn't believe what I was seeing, but that was such great news!"

It was an incredibly rewarding feeling. All the studying, practice exams, and hours spent learning AWS had finally paid off.

That evening, I sat on the couch with my laptop and took a moment to reflect on everything that had happened that day.

Passing the exam felt amazing, but I found myself thinking about something deeper.

What does this certification really mean to me?

What value did I gain from this journey?

How did I get here?

Was it worth six months of evenings and weekends?

As I thought through those questions, I realized the certification was more than just a badge.

It represented the hours spent learning, building, experimenting, making mistakes, and continuing to grow as an engineer.

Six months ago, I made a commitment to myself.

I was going to earn the AWS Certified Solutions Architect – Associate certification.

I also made one promise:

My study time would happen outside of work.

That meant evenings after work and weekends. I wanted this to be something I personally invested in.

My goal was simple:

Take the exam before the end of Q2 2026.

One hour at a time.

Day after day.

I watched courses on Pluralsight, filled notebooks with notes, and challenged myself to explain every concept in my own words.

I wasn't trying to memorize answers.

I wanted to understand why AWS services exist, when to use them, and the trade-offs behind each architectural decision.

One month passed.

Then two.

Then three.

Four.

Five.

Eventually, studying became part of my routine.

Some days were exciting because I discovered new services or architectural patterns.

Other days sent me down rabbit holes where learning one AWS service naturally led to three more.

Looking back, I realized preparing for the certification wasn't just about passing an exam.

It was about learning how to think like a solutions architect.

The practice exams—and especially the real exam—forced me to slow down and carefully evaluate every answer.

Many questions contained options that looked almost identical.

The challenge wasn't simply knowing what Amazon SQS or Amazon SNS does.

It was understanding why one service was the better architectural choice for that specific scenario.

That shift in thinking became one of the biggest lessons from the entire journey.

The certification validated my knowledge.

The learning process transformed the way I approach architecture decisions.

One thing I realized throughout this journey is that my day-to-day work doesn't always involve AWS.

That's exactly why pursuing this certification mattered so much.

It gave me the freedom to intentionally invest in learning AWS, experiment with new services, and deepen my understanding of cloud architecture outside of my regular responsibilities.

Since earning the certification, I've continued building serverless projects, experimenting with AI, writing technical articles, and finding new ways to apply what I've learned.

For me, this certification isn't the finish line.

It's another milestone in a much longer journey of continuous learning.

If you're looking for someone who's passionate about AWS, serverless architectures, AI, and building practical solutions, I'd love to connect.

Whether it's exchanging ideas, collaborating on projects, or discussing opportunities, feel free to reach out.

Looking back, earning the certification wasn't the hardest part.

The hardest part was showing up consistently, one hour at a time, for six months.

I'm grateful I made that commitment to myself.

"Because every difficult challenge we choose today becomes the confidence we carry into tomorrow."

What's your thought on this?

What happens when curiosity meets your AWS Credit?

Nadtakan Futhoem (Nad) — Wed, 17 Jun 2026 15:20:02 +0000

I recently had my AWS Community Builder membership extended for another year, and I'm excited to continue building alongside so many talented people in the community.

One of the benefits of the program is AWS credits. As developers, having the freedom to experiment and build without constantly worrying about costs is incredibly valuable.

When I received my credits, I started thinking about what I wanted to build next.

My first thought was Kiro.

Since AWS credits work with Kiro, I set up IAM Identity Center, connected my account, and was ready to go.

Done, right?

Not quite.

The next question immediately became:

"Now what?"

I knew I wanted to build something serverless, but I wasn't sure what.

I started thinking about writing a monthly article summarizing AWS releases and announcements. The challenge was figuring out how to keep up with everything AWS ships.

My first idea was simple:

"Just check the AWS announcements page every day."

Problem solved.

Or so I thought.

Not everyone has time to manually monitor AWS releases every day.

After some research, I discovered AWS RSS feeds that publish release announcements as they happen.

Now things got interesting.

The first version of the project was straightforward:

• Fetch announcements from RSS feeds
• Store them in Amazon S3
• Display them on a webpage

But I wanted more than a feed reader.

I wanted AI to help answer a question I personally care about:

"How does this announcement impact my daily work or personal projects?"

That changed everything.

Instead of simply storing content in S3, I moved toward DynamoDB so I could store structured data alongside each release:

• AI-generated summaries
• Impact analysis
• Categorization
• Additional metadata and insights

Over the course of a day, Kiro helped me build much of the foundation. My role shifted from writing every line of code to making architectural decisions and guiding the implementation.

That said, I still jump into the code regularly. Sometimes I tweak features, optimize workflows, or dig into the implementation to understand what’s happening under the hood. I enjoy coding, and I don’t want to lose that muscle. Tools like Kiro help me move faster, but staying hands-on keeps me sharp as an engineer.

One of the most interesting discussions wasn’t about code at all—it was about cost optimization.

Should the system write a new record every time it processes a release?

Or should it only write when a release doesn’t already exist?

Small decisions like these have a big impact on cost, scalability, and operational efficiency.

What started as "I have AWS credits to spend" evolved into an AI-powered AWS release analysis platform.

And honestly, that's one of my favorite parts of building.

You start with one idea, discover a better one, and keep iterating until the project becomes something you never originally planned.

Here's the evolution of the project from V1 to V2.

What started as a simple RSS-to-webpage pipeline evolved into an AI-powered AWS release analysis platform that helps me focus on the AWS services and topics I care about while also understanding how new releases might impact my work and personal projects.

V1 vs. V2 Architecture

The project is open source, and you can also explore the live version here.

Feel free to clone it, deploy it to your own AWS account, and make it your own.

Whether you want a quick way to stay on top of AWS releases or you're interested in extending the functionality, I hope it provides a useful starting point.

If you have ideas, suggestions, or improvements, I'd love to hear them. Open an issue, submit a PR, or send me a message.

I'm especially curious how others are using AI alongside serverless architectures.

How are you using AI in your side projects today?

Leave me a comment; until next time!

Nad

re:invent 15 things I wish I knew about securing my AWS account

Nadtakan Futhoem (Nad) — Wed, 02 Dec 2020 20:11:09 +0000

1. Enforcing MFA with YubiKeys and AWS Config rule

MFA เป็นอีกวิธีหนึ่งที่ช่วยเพิ่มการป้องกันคนอื่นที่รู้รหัสของเราไม่ให้สามารถเข้าใช้งานส่วนมากเราจะใช้โทรศัพท์ในการติดตั้ง MFA แต่ปัญหาส่วนใหญ่ที่เกิดจากการใช้มือถือคือถ้าเราลืมชาร์ตแบตมือถือ แล้วแบตเราหมด หรือไม่สามารถเข้าใช้งาน MFA แอพพลิเคชั่น ซึ่งทำให้เราไม่สามารถเข้าใช้งาน MFA ได้

Yubikeys เป็นอีกทางเลือกหนึ่งที่สามารถช่วยให้เราสามารถเข้าใช้งาน AWS ได้ Yubikey ไม่จำเป็นต้องชารต์แบตและสามารถปลดล๊อกโดยการสัมผัส

AWS config rule จะเป็นอีกทางเลือกที่ช่วยตรวจสอบว่า MFA แอพมีการใช้งานหรือไม่สำหรับแอคเคานั้น ถ้าผู้ใช้งานไม่มีการติดตั้ง MFA เราสามารถตั้งค่าให้แอคเคานั้นไม่สามารถเข้าใช้งานจนกว่าผู้ใช้งานจะเปิดใช้งาน MFA

2. Traffic baseline with Amazon VPC flow logs

Baseline เป็นการดับจับข้อมูลผ่านเข้าออกที่ผิดปกติไปจากดั้งเดิม VPC flow logs จะมีการเก็บข้อมูลไว้และเราสามารถใช้ข้อมูลนี้เป็นในการวิเคราะห์ถ้าหากมีข้อมูลที่ผิดปกติไปจากเดิม

3. Beyond 90 days with AWS CloudTrail

CloudTrail เก็บข้อมูลทุกอย่างที่เกิดขึ้นใน AWS แอคเคาท์ ซึ่งถ้าหากเราคิดว่าแอคเคาท์เราเกิดการรั่วไหลข้อมูล เช่น รหัสผ่าน หรือมีคนพยายามที่จะแฮค เราสามารถเปิด history ใน CloudTrail เพื่อค้นหาข้อมูลความเคลื่อนไหว
ClouTrail สามารถเปิดข้อมูลย้อนหลังได้ 90 วัน แต่ถ้าหากเราต้องการที่จะเก็บข้อมูลมากกว่านั้น เราสามารถตั้งค่าการเก็บข้อมูลโดยใช้ s3 แยกเก็บในอีกแอคเคาท์

4. Threat detection with AWS Detective and Amazon GuardDury

Threat detection เป็นการวิเคราะห์ข้อมูลความเคลื่อนไหวที่ผิดปกติไปจากเดิมใน AWS แอคเคาท์

5. Exploring access with AWS CloudTrail and Amazon Athena

Athena เป็นเครื่องมือที่ช่วยในการเลือกข้อมูลที่เราต้องการโดยใช้ SQL query ซึ่งทำให้ลดเวลาในการอ่านไฟล์ทุกไฟล์

6. Isolate workloads with multiple AWS accounts

เพื่อป้องกัน Blast Radius AWS แนะนำให้เราแยกแอคเคาท์ออกจากกัน

7. Harden EC2 instances from the Amazon EC2 marketplace

Harden EC2 instance ช่วยในตั้งค่าที่ถูกต้องสำหรับ ec2 โดยที่เราไม่จำเป็นต้องใช้เวลาในส่วนนี้

8. Ditch key pairs in favor of AWS Systems Manager Session Manager

ปกติเวลาที่เข้าใช้งาน ec2 เราจะใช้ SSH key ในการเข้าถึง แต่ถ้าหากทีมของเราลาออกหรือมีการแชร์ไฟล์นี้ออกไป คนอื่นสามารถเข้าใช้งาน ec2 ของเราได้
Session Manager เป็นอีกทางเลือกหนึ่งที่ปลอดภัยกว่า ซึ่งไม่จำเป็นต้องใช้ key เราสามารถดูการเคลื่อนไหวย้อนหลัง และสามารถจำกัดการเข้าใช้งาน

9. Principle of least privilege via IAM policies

ตั้งค่า IAM policy เป็นอีกสิ่งหนึ่งที่สำคัญมากสำหรับ production ซึ่ง AWS แนะนำให้ตั้งค่า action และ resources สำหรับสิ่งที่เราต้องการใช้จริงๆ

*10. Lock Regions and services with service control policies
*

service control policies (SCP)เราสามารถตั้งค่าเพื่อจำกัดการใช้งานแต่ละ region ได้

11. Allow trusted IPs through to AWS WAF

AWS WAF ใช้สำหรับการตั้งค่า IP adress เฉพาะแอดมินแอคเคาท์ และบล๊อกการเค้าถึงจากบุคคลอื่นๆ

12. Clearing an account with aws-nuke

aws-nuke ช่วยในการลบแอคเคาท์ที่เราไม่ต้องการเพื่อลดค่าใช้จ่ายถ้าไม่มีการใช้งาน

13. Start compliance with AWS Config conformance packs

14. Avoid data unintended leaks with IAM Access Analyzer

AWS IAM Access Analyzer ช่วยในการดับจับความเคลื่อนไหวใน AWS แอคเคาท์ และการแชร์ resouces

15. Where to go next with AWS Well-Architected Tool(Security Pillar)