Forem: sazecis

Think AWS Recertification Is Easy? Nope!

sazecis — Wed, 26 Feb 2025 20:33:55 +0000

Lots of people don’t know this, but AWS recertification exams aren’t any shorter or simpler. They’re the same exact exams as the first time. Same price, same way to sign up and take them too.

I just recertified in three big ones: AWS Certified Solutions Architect – Professional, AWS Certified DevOps Engineer – Professional, and AWS Certified Security – Specialty. My friends kept asking, “Which is the hardest?” I’d say, “Depends—what do you know best? What did you study? Where’s your experience at?” They didn’t like that answer much. They’d argue the Solutions Architect Professional is the toughest.

So, since I did all three exams with just a week between them, I’ve got a fresh take to compare them.

The Basic Numbers

Here’s how it breaks down:

Solutions Architect Pro & DevOps Engineer Pro: 180 minutes (210 for me, non-native English speaker), 75 questions.
Security Specialty: 170 minutes (200 for me), 65 questions.

Security Specialty already sounds less heavy—fewer questions, only 10 minutes less time. But is it really easier? Let’s see.

Security Specialty: The Easiest One?

Spoiler: Security Specialty felt easiest out of the three. It’s not just the 65 questions compared to 75 in the Professional exams. The questions weren’t as tricky either. Here’s some quick math:

I finished Security 40 minutes early, even with my extra 30 minutes. That’s 160 minutes for 65 questions—less than the standard 170, so I didn’t even need the extra time! The Professional exams? Took me the full 210 minutes for 75 questions (well, 205 for DevOps, but close enough). Average it out:

Professional exams: 2.8 minutes per question (210 ÷ 75).
Security Specialty: 2.5 minutes per question (160 ÷ 65).

Caption: “Security questions didn’t eat my brain as much.”

That’s about 11% less time per question — Security ones were definitely easier. Now, you might say, “This only works if you studied the same for all three.” Well, I did—or didn’t, depending how you look at it. I didn’t study at all, unless you count 8 years of my AWS job as studying.

My daily AWS job is what got me ready, not a study plan. For me these exams were more about proving what I know already.

So, the comparison holds up.

Solutions Architect vs. DevOps Engineer

Now the two big ones: Solutions Architect Pro versus DevOps Engineer Pro. Both have 75 questions and 210 minutes for me. I used all the time on Solutions Architect, and I had like 5 minutes left on DevOps—so, almost the same deal.

My DevOps score was 60 points higher, so maybe it was easier. But both? Super tough. After 3.5 hours, my head was done — no more work that day. Security Specialty? Finished it, went home, worked 4 more hours, no problem.

Feeling-wise, Security was way less exhausting, maybe half as bad as the Professional exams. I was thinking here was it really so much easier or I just got more practice in security which is the job zero, and it's everywhere, you work with it the most ... nah it was easier 😄

Which Pro Wins the Hard Prize?

You probably want me to pick between the two Professional exams. Okay, my opinion: DevOps Engineer Pro felt a tiny bit harder than Solutions Architect Pro. But I’m still saying what I said before—it depends on you.

How much you prepped, which AWS services you know well, that’s what matters. I’ve been a Solutions Architect and Technical Trainer for years, so I get the big architecture picture. Maybe that’s why Solutions Architect wasn’t as rough for me as DevOps.

Demonstrating the usage of AWS Developer Tools with a serverless application

sazecis — Tue, 07 Mar 2023 13:19:09 +0000

Serverless computing is one of the most innovative and modern ways of building applications. It offers a way to run applications without the need to manage servers or infrastructure. In this blog post, we will explore how to build a serverless Bookshelf application on Amazon Web Services (AWS) using a set of powerful and flexible tools and services.

The Bookshelf application used in the demonstration is a simple application that allows authenticated users to view a list of books. We will use several AWS services to build the application, including Amazon S3, Amazon DynamoDB, AWS Lambda, Amazon API Gateway, and Amazon Cognito.

To go through the process of building the serverless application, I have created a step-by-step guide in the form of a README file available on my GitHub repository. The repository also includes all the code and configurations required to build the application. You can find the repository here: https://github.com/sazecis/aws-dev-examples.

Architecture Diagram:

The following diagram illustrates the architecture of the Bookshelf application:

As you can see in the diagram, the Bookshelf application uses several AWS services, including Amazon S3, Amazon DynamoDB, AWS Lambda, Amazon API Gateway, and Amazon Cognito. The application's static content is hosted on Amazon S3, and the Bookshelf data is stored in Amazon DynamoDB. AWS Lambda is used to read the Bookshelf data from DynamoDB, and Amazon API Gateway is used to expose the Bookshelf data to the internet. Amazon Cognito is used to authenticate and authorize users accessing the Bookshelf data.

Building the Application:

To build the Bookshelf application, we will use the AWS SDKs and Command Line Interface (CLI) tools. We will start by creating an Amazon S3 bucket and hosting the static content of the application on it. Next, we will create an Amazon DynamoDB table to store the Bookshelf data. We will then create an AWS Lambda function that reads the Bookshelf data from DynamoDB and exposes it through an Amazon API Gateway REST API. Finally, we will secure the Bookshelf API using Amazon Cognito as an authorizer.

The whole application deployment is willingly not done with full automation. Manual steps are part of the demo. The manual steps are described in the README and are dependent on each other.

Have fun and please leave your comment either here or directly at my repository.

Folding as a Service with AWS StepFunctions

sazecis — Mon, 23 Jan 2023 11:58:11 +0000

I am an AWS Solution Architect and I had been working with cloud technologies for many years. I had always been interested in using my technical skills to contribute to something meaningful. In 2020, when the COVID-19 pandemic was in full swing, I came across an article about the Folding@home project, which uses spare processing power of personal computers to perform complex simulations of protein folding. I realized that by using my own home computer, I could contribute to the project and help researchers understand how proteins fold and misfold, which in turn can aid in the development of new drugs and treatments for COVID-19 and other diseases.

One day, while I was thinking about how to increase my computer's processing power and efficiency, I had an idea: why not use the cloud? I knew that with the vast resources and flexibility of a cloud computing platform like Amazon Web Services (AWS), I could run simulations on a much larger scale and speed up the discovery process. So, I set up a virtual machine on AWS and started running the Folding@home simulations on it. The results were astounding, my computer's processing power increased, and I was able to perform more complex simulations and make new discoveries at a much faster rate. However, I soon realized that running Folding@home on the cloud was too expensive for my personal budget.

I couldn't let go of the idea. I thought that there might be other people or companies who would like to contribute with some compute resources but don't know how to use the folding. So, I came up with the idea of providing a "Folding as a Service" solution where contributors just specify the amount of money they want to donate and based on that, the infrastructure will be automatically generated and will run the foldings until the credit runs out. This way, I can help more people and organizations contribute to the Folding@home project and potentially researchers find cures for diseases more quickly.

Still in 2020, I took action and put the idea of "Folding as a Service" into practice. I built the service using Step Functions, Lambda, DynamoDB, EC2 and more. The Step Function was designed to take an input of credits in dollars and based on that, it would automatically start and configure a single EC2 instance. Several Lambda tasks were used to start and stop the Folding@home instance, monitor the performance of the instance, and make sure it was running efficiently. DynamoDB was used to keep track of the credit consumption.

I had the idea to put this whole service behind a website and create an easy-to-use user interface which would allow anyone to access the service and contribute to the Folding@home project with a few simple clicks, regardless of their technical expertise. I finished the backend service but because of lack of time did not start to work with the user interface. The solution stood unused until recently when I started to do some open-source contributions.

The other trigger which took me back to my dusty idea happened during the re:Invent conference, where I learned about a new service called AWS Application Composer. I wanted to test this service and explore its capabilities, and I decided to use my old Folding as a Service solution as a demo. I decided to recreate its infrastructure using the AWS Application Composer. Using the Application Composer wasn't so trivial but still it provided me with a good head start, and I was able to use the basic SAM template generated by it. I found that the Application Composer can be a great tool for serverless application designing, planning, and implementation, but as soon you need to include non-serverless resources, like in my case the tool can't be used any more. Still let me show you the initial diagram which I created:

The SAM template is a special CloudFormation template. CloudFormation is not my favorite tool, but still I decided to stick with it for this particular case. The reason for that was that I wanted to have a project using SAM.

Now these tools allowed me to create the infrastructure as code, update the scripts, and develop a working Folding as a Service solution that runs on EC2 spot instances, and can fold both with CPU or GPU setups. The solution is open-source, and anyone can clone my repository (https://github.com/sazecis/folding-as-a-service), build it, and deploy it to their own AWS account. If anyone is interested in more details on how to deploy the solution, they should read the README file of the repository or check out the diagram below:

After deployment, the folding process will not start automatically, it needs to be triggered by executing the Step Function and specifying the credit which you want to spend. This solution is ideal for individuals and organizations who have unused AWS credits or wish to contribute to the Folding@home project. The process of setting it up is straightforward, making it easy to contribute to the fight against diseases.

There are still many potentials in this solution, and it can be implemented for other Cloud Providers as well. Implementing a user-friendly interface would bring in more users and be a significant breakthrough. However, I am taking it step by step. And of course, if anyone is interested in joining the project, please feel free to contact me. Join the project and let's make a difference together.

Well-Architecting Review Optimization at T-Systems: The Role of the AWS Well-Architected Framework and the aws-wafr-cli Tool

sazecis — Fri, 20 Jan 2023 14:33:08 +0000

The AWS Well-Architected Framework is a set of guidelines and best practices for designing and operating systems in the cloud that are reliable, secure, efficient, and cost-effective. T-Systems, as an AWS Premier Consulting Partner, offers AWS consulting services to its customers and also conducts regular Well-Architected reviews. However, during these reviews, a significant amount of time is often spent on tasks that are already covered by the internal Landing Zone solutions. To streamline this repetitive and time-consuming process, T-Systems has developed a command-line interface (CLI) tool called aws-wafr-cli. This tool allows for faster and more efficient Well-Architected reviews.

The aws-wafr-cli tool is built using Python and the boto3 library. It can be used to create or update Well-Architected Tool workloads with preconfigured answers that have already been solved e.g. by central Landing Zone solutions. Additionally, the tool can be used to migrate workloads from one account to another, store custom lens templates, and publish them to your AWS accounts.

The aws-wafr-cli tool is open-source and available on GitHub. It is designed to be easy to use and can be installed with just a few simple commands. It can help you to optimize your EKS workloads and ensure that they are aligned with the best practices and guidelines outlined in the AWS Well-Architected Framework.

One of the key benefits of using the aws-wafr-cli tool is that it allows you to standardize and automate the review process across multiple accounts and regions, making it easier to identify and address areas for improvement. The tool can also be used to generate custom lens templates for EKS clusters, which can be used to ensure that your clusters are aligned with your organization's specific security and compliance requirements.

T-Systems has already performed several EKS reviews with the help of this tool and with the help of its own Managed EKS service. This allowed us to gain valuable insights and experience in reviewing and optimizing EKS workloads and to ensure that our customers have a secure and reliable service.

In conclusion, this tool allows us to streamline the process of reviewing and optimizing our customers' workloads. By utilizing the AWS Well-Architected Framework and the aws-wafr-cli tool, we are able to ensure that our customers' systems are reliable, secure, efficient, and cost-effective, while also reducing the time and effort required to perform reviews.

If you're an AWS customer looking to optimize your EKS workloads, or if you're an AWS partner looking to streamline your review process, the aws-wafr-cli tool is a valuable resource that can help you to achieve your goals faster.

If you're interested in learning more about the aws-wafr-cli tool, or if you're looking for assistance with optimizing your EKS workloads, please don't hesitate to reach out to us. We're always happy to help and provide guidance on how to best use the tool and the Well-Architected Framework in general.