Forem: Ifeanyi O.

Amazon S3 Files Is Still Not A File System

Ifeanyi O. — Thu, 09 Apr 2026 21:24:02 +0000

Intro
What is S3 Files
What Changed for Developers
How S3 Files Works at a High Level
Why This Matters for AI
Practical Code Example
Security Operations
Key Takeaways

Intro

If you've spent any real time learning AWS, one of the first storage lessons you probably learned was Amazon S3 is not a file system.

And that mattered because it explained a lot of the weirdness you'd run into early on that might have you asking...

Why can't I just mount S3 like a normal shared drive?
Why can't my application treat S3 data like regular files?

But the answer has always been... S3 is object storage and even though that's obvious, it's a critical distinction because as interesting as S3 Files is, it seems to be confusing a lot of people that only read headlines.

So no... S3 did not suddenly turn into a file system.

So what is S3 Files?

S3 Files is a file system interface for data that lives in S3 and connects AWS compute resources directly with data in S3. It gives applications file system access without the data ever leaving S3 and maintains a view of the objects in the bucket while translating file system operations into efficient S3 requests.

Personally, the simple way to think about S3 Files is S3 remains the storage layer, S3 Files becomes the file-access layer and your apps sees files and directories.

What changed for developers

Before S3 Files, many workloads had a choice to make.

Do you optimize for S3's scalability, durability and cost characteristics, or do you optimize for file system behavior that your applications already understand?

S3 Files aims to remove that tradeoff by making general purpose S3 buckets accessible as native file systems for AWS compute resources and supports NFS v4.1+ file operations like create, read, update and delete.

This is kind of a big deal because it means more workloads can work against data where it already lives instead of forcing you to move it somewhere else first.

How S3 Files works at a high level

At a high level, S3 Files creates a file system view over an S3 bucket.

Your compute resource connects to that file system through a mount target in your VPC. For example, you can create the S3 file system, discover the mount target and then mount it from an EC2 instance using the s3files file system type.

Once mounted, your application can interact with the mounted path using normal file operations.

sudo mkdir /home/ec2-user/s3files
sudo mount -t s3files fs-1234567890abcdef:/ /home/ec2-user/s3files

After that, you can do familiar things like:

echo "Hello S3 Files" > /home/ec2-user/s3files/hello.txt
ls -al /home/ec2-user/s3files/hello.txt

When you create a file through the mounted file system, the file appears in the S3 bucket as an object and the contents remain the same when retrieved through the S3 API.

That is the key idea in action and even thought you're working through the file interface, S3 still stores the data underneath.

Why this matters for AI

S3 Files is clearly positioned for agents, machine learning and collaborative data-heavy workloads.

The announcement page specifically calls out file-based applications, agents and ML teams as beneficiaries. It states that AI agents can persist memory and share state across pipelines, ML teams can run data preparation workloads without duplicating or staging files first and thousands of compute resources can connect to the same S3 file system simultaneously.

That makes sense.

A lot of modern AI and ML tooling still behaves in very file-centric ways. Training inputs, checkpoints, logs, intermediate artifacts and tool-driven workflows often assume files and directories are available. Even when your long-term storage strategy is object-first, the workloads themselves may still be file-first.

Practical code example

Here's a simple way to show the difference conceptually:

Let's look at working directly with S3 objects in Python.

import boto3
s3 = boto3.client("s3")
bucket = "my-data-bucket"
key = "reports/summary.txt"
response = s3.get_object(Bucket=bucket, Key=key)
content = response["Body"].read().decode("utf-8")
print(content)

That works fine, but your code is explicitly written around the S3 API model.

Now let's review working with a mounted S3 Files path.

file_path = "/mnt/s3files/reports/summary.txt"
with open(file_path, "r") as f:
    content = f.read()
print(content)

The second version feels ordinary because it is ordinary from the application's point of view.

Security and operational details worth noting

S3 Files integrates with IAM for access control, supports identity and resource policies at both the file system and object level, encrypts data in transit with TLS 1.3 and supports encryption at rest with SSE-S3 or customer-managed AWS KMS keys. It can also monitor it using CloudWatch metrics and CloudTrail management events.

So we can treat this as a real production service with access control, encryption and observability expectations teams will need.

Key takeaways for developers

The biggest takeaway is that the boundary between object storage workflows and file-based workflows has got much easier to work across.

That matters because a lot of cloud architecture pain comes from interfaces not matching reality forces teams to build adapters, stage pipelines, duplicate storage systems and synchronize logic just to keep things moving.

S3 Files now gives you the option to say, "maybe I shouldn't have to do that nearly as often."

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

If you've got this far, thanks for reading! I hope it was worthwhile.

5 AWS Services New Developers Struggle With (And Why)

Ifeanyi O. — Tue, 07 Apr 2026 10:25:45 +0000

Intro
Identity and Access Management
Virtual Private Cloud
Simple Queue Service Vs Simple Notification Service
CloudFormation
CloudWatch
Why These Services Matter

Intro

Okay... let's be honest for a second.

When you first opened the AWS Console, which service made you pause a little longer than the others? And I don't mean in a curious way but in a “wait… what the heck is actually going on here?” kind of way.

AWS is extremely powerful and that’s part of the appeal. But with great power and limited context, you can feel overwhelmed, especially when you’re no longer working in a personal account.

Yes, there are over 200 AWS services and most teams will rely heavily on a small subset but there are a select few that almost every new developer runs into early on and quietly struggles with.

It's usually not because they’re innately complex to understand, but because they require a mental shift most new developers haven’t made yet.

In this blog, we'll address five AWS services new developers struggle with which includes, AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (VPC), knowing the difference between Amazon Simple Queue Service (SQS) and Amazon Simple Notification Service (SNS) and when to use which, AWS CloudFormation and Amazon CloudWatch.

IAM

AWS Identity and Access Management is the control plane gatekeeper. Every action performed in AWS eventually becomes an API call and every API call is evaluated by the IAM policy engine before it is allowed to proceed.

This is where new developers first encounter friction because IAM is deterministic but not always obvious. When you receive an AccessDenied error, this is the result of a precise evaluation process that has determined the request should not be allowed.

When a request is made, AWS evaluates the principal making the request, the action being requested, the resource being accessed and any conditions that apply. That principal could be an IAM user, an assumed role, a federated identity, or a service role attached to a resources like an AWS Lambda function or Amazon EC2 instance. Developers often forget that once code runs in AWS, it is no longer acting as "you" but actually acting as the role attached to the compute resource.

IAM evaluation considers identity-based policies attached to the principal, resource-based policies attached to the target resource, permission boundaries that may restrict the maximum allowed permissions of that principal and Service Control Policies (SCP) applied at the organizational level. If any applicable policy contains an explicit deny that matches the request, the request fails immediately, even if other policies allow it.

This layered evaluation model is what confuses many developers. A developer may attach a policy granting permission to read from an S3 bucket, but the bucket policy may restrict access to requests originating from a specific VPC endpoint, or the organization may enforce an SCP preventing certain API calls entirely, or the role being assumed in a CI/CD pipeline may not include the permissions the developer tested locally.

To make this more concrete, let's consider a simple identity-based policy that allows reading from an S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

At a glance, this policy appears sufficient as it allows the required action on the expected resource. However, IAM does not evaluate this policy in isolation. If a bucket policy restricts access to a specific network path, or an organizational policy blocks the action entirely, or the request is coming from a different role than expected, the final decision may still be a denial. The presence of an allow statement does not guarantee access if another layer introduces a conflicting rule.

IAM also introduces conditional logic. Access can be restricted based on IP address, multi-factor authentication presence, encryption state, resource tags, or request context. Two seemingly identical API calls can produce different results based on environment.

Let's review this updated identity-based policy that introduces an additional requirement:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-app-bucket/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    }
  }
}

The same request will succeed or fail depending on whether it is made over HTTPS.

For most developers, what makes IAM difficult early is that it forces you to think like a policy engine and start asking questions like, “Which principal is making this request and which policies are being evaluated?”

However, once you understand the deterministic evaluation system of IAM policies, your debugging episodes will become more systematic and efficient.

VPC

Many developers don’t think deeply about networking early in their careers. Things usually just connect locally, APIs call databases and everything just works. However, when you join an actual team and start hearing phrases like, “It's in a private subnet,” or “The security group won’t allow that traffic,” or “There’s no route to the NAT gateway,” that's when you realize your lack of depth in cloud networking concepts and resources.

For understanding, a VPC defines the networking boundaries of your AWS environment. It determines which resources are public, which are private, how traffic flows and what is allowed to communicate with what. Subnets, route tables, internet gateways, NAT gateways, security groups and network ACLs all play a role.

The reason new developers struggle with VPC is that networking is often abstracted until things begin to fail. You might deploy a Lambda function and wonder why it can’t connect to a database. Both the function and the database exists but if they’re in different subnets without proper routing or security group rules, they might as well be on separate planets.

On AWS, connectivity explicit. Just because two resources exist does not mean they automatically can talk to each other. Traffic MUST be intentionally allowed.

Let's consider what happens when a resource needs internet access from a private subnet. That path does not exist by default and must be explicitly defined through routing.

Below is an example of a route table entry that allows traffic from a subnet to reach the internet through a NAT Gateway:

Destination: 0.0.0.0/0
Target: nat-0abc123example

This single route determines whether instances in that subnet can reach external services like APIs, package repositories, or external databases. Without it, outbound traffic has nowhere to go, even if everything else appears to be configured correctly.

Similarly, security groups act as virtual firewalls at the resource level. Even if routing is correct, traffic can still be blocked if the security group does not explicitly allow it.

For example, a database security group might only allow inbound traffic on port 5432 from a specific application security group:

Type: PostgreSQL
Port: 5432
Source: sg-0appserver123

In this case, even if another resource is in the same VPC and subnet, it will not be able to connect unless it is associated with the allowed security group so connectivity cannot be assumed. It has to be defined.

As a developer trying to grasp networking on AWS, at first, it might feel like a maze with invisible walls... and that's okay. Once you start visualizing the path a request takes, from the client through a load balancer, into a subnet, through a security group and into a database, understanding VPC will become easier to reason about.

SQS vs SNS

Almost every new developer gets confused by Amazon SQS and Amazon SNS at some point. They both move messages, are used in event-driven systems and are often mentioned together in architectural diagrams. So the question is... what’s the difference?

For starters, Amazon SQS is basically a queue. Messages sit there until something pulls them and processes them. On the contrary, Amazon SNS is a publish-and-subscribe service where messages are pushed to subscribers when they are published.

This sounds simple, but the confusion comes from how they’re used together. You’ll see architectures where an S3 event triggers an SNS topic, which then fans out to multiple SQS queues, then trigger Lambda functions or you’ll see an SNS topic directly invoking endpoints and maybe EventBridge involved somewhere in the mix. As more services are integrated, suddenly, the flow of data feels less obvious.

Let's review what it looks like to publish a message to an SNS topic:

import boto3

sns = boto3.client('sns')

response = sns.publish(
    TopicArn='arn:aws:sns:us-east-1:123456789012:my-topic',
    Message='Order created'
)

The moment this message is published, SNS immediately pushes it to all of its subscribers. That could include multiple SQS queues, Lambda functions, or even HTTP endpoints. The publisher does not need to know who those subscribers are, it simply emits the event.

Now compare that to SQS. Messages are not pushed to consumers, they remain in the queue until something explicitly retrieves (pulls) them:

import boto3

sqs = boto3.client('sqs')

response = sqs.receive_message(
    QueueUrl='https://sqs.us-east-1.amazonaws.com/123456789012/my-queue',
    MaxNumberOfMessages=1
)

messages = response.get('Messages', [])

In this case, the consumer is responsible for polling the queue, retrieving messages and processing them. If no consumer is running, the message simply stays in the queue.

The real struggle here is not in the intricacies of the syntax of the services, it's more about the architectural thinking that's require here. You have to ask questions like, "Do I need multiple consumers?", "Do I need messages to persist until they’re processed?", "What happens if a consumer fails?", "Will this message be retried?", "Could it be processed twice?" and this is where the distinction becomes meaningful.

SQS gives you durability and control over processing. Messages persist until they are handled, which makes it useful when you need reliability and buffering between systems. SNS gives you immediacy and fan-out. It is designed to broadcast events to multiple systems at once without tightly coupling them.

Additionally, messaging introduces distributed systems concepts like at-least-once delivery and idempotency. For many developers, this is the first time they have to think beyond simple request-response patterns like when a message may be delivered more than once, a consumer may fail mid-processing, or systems may process events at different speeds.

This is how SQS and SNS can feel confusing complex early because the real challenge is understanding how they behave when systems are no longer tightly connected and operations don't happen in a single request-response cycle.

CloudFormation

At some point, you’ll try to modify a resource in the AWS Console and get a message telling you that the resource is managed by CloudFormation and that's you'll realize that you’re interacting with infrastructure defined as code.

AWS CloudFormation allows teams to define infrastructure in templates and deploy it as stacks and those stacks become the source of truth. If something is defined in a template, manual console changes are temporary at best and overwritten at worst.

New developers struggle here because it requires discipline and patience. You can’t just click and tweak something quickly, you need to find the template, understand how the resource is defined, update it properly and redeploy the stack. Additionally, when a stack update fails, the error messages can be intimidating.

Let's look at a simple CloudFormation template that defines an S3 bucket:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-app-bucket-123

This template does not describe how to create the bucket step by step. Instead, it defines that a bucket with this name, my-app-bucket-123, should exist. When deployed, CloudFormation creates and manages that resource as part of a stack.

If you later change the bucket name in the template and redeploy, CloudFormation will determine what needs to change to match the new desired state. That might mean replacing the resource entirely, which is why understanding updates is just as important as initial creation.

CloudFormation forces you to think declaratively. Instead of saying, “Create this resource,” you define the desired state and let AWS reconcile the difference. It’s a powerful approach, but it changes how you work. It also means most of what you’re touching likely existed before you arrived and was created intentionally through code.

New developers have to intentionally learn to stop treating the console as the place to make changes and start treating CloudFormation templates as the source of truth. Once you understand that every update goes through the stack, even when something fails, you'll know where to look to fix it.

CloudWatch

As a new developer, you'll be focusing on building features so observability can sometimes feel like a secondary task. However, the minute something breaks in production, then suddenly logs and metrics are all anyone cares about.

Amazon CloudWatch is where you go to understand what your systems are actually doing in real time as it handles logs, metrics, alarms and dashboards but it does not interpret the data for you. What you get is raw signals that you have to make sense of them.

You might open a log group and scroll through hundreds of lines without knowing what you’re looking for, or see a metric spike but not know what "normal" even looks like, or even wonder why an alarm didn’t trigger when you expected it to.

Let's look at what a simple log entry from a Lambda function might look like:

2026-03-31T14:22:10.123Z  ERROR  Failed to process orderId=12345
Traceback (most recent call last):
  File "/var/task/app.py", line 42, in handler
    process_order(order)
Exception: Database connection timeout

At a glance, this tells you something failed, but in a distributed system, this is rarely the full story. The database might be in a different subnet, behind a security group, or experiencing latency issues, so the log gives you a clue, but it's not the complete answer.

Now consider a metric that tracks errors over time:

Metric: Errors
Namespace: AWS/Lambda
Statistic: Sum
Period: 5 minutes

If this metric spikes, CloudWatch can trigger an alarm:

Alarm: LambdaErrorAlarm
Threshold: Errors > 5
Evaluation Period: 1 datapoint
Action: Send notification to SNS topic

Even here, interpretation is required. Is five errors in five minutes abnormal? Is that a real issue or expected behavior during traffic spikes? CloudWatch provides the signal, but it does not define what is meaningful.

The challenge here is that debugging in distributed systems is very different from debugging locally. There’s no single stack trace that tells the whole story and you have to piece together information across services.

The good news is overtime, you will build intuition and learn which metrics matter, how to structure logs and when to create alarms. But early on, CloudWatch can feel overwhelming as it exposes the complexity of production systems in it's full detail.

Why These Five Services Matter

As a new developer, these five services show up early because they sit at the foundation of how systems are built and operated.

IAM teaches you to think in terms of identity and authorization, VPC teaches you to understand network boundaries and traffic flow, SQS and SNS introduce you to distributed and event-driven thinking, CloudFormation forces you to respect infrastructure as code and existing systems and CloudWatch pushes you to think operationally and observe before you optimize.

They represent transitions in how you think as a developer working in the cloud.

If you’re struggling with one of them right now, don't worry. It’s usually a sign that you’re growing. Every developer who works seriously in AWS goes through a growing phase. The difference over time is that what once felt confusing will eventually become familiar.

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

Good luck!

If you've got this far, thanks for reading! I hope it was worthwhile.

5 Common AWS Errors New Developers Hit (And How to Fix Them)

Ifeanyi O. — Wed, 11 Mar 2026 10:00:00 +0000

Intro
AccessDenied
InvalidClientTokenId
ThrottlingException
ResourceNotFoundException
ValidationException
Patterns Behind the Errors

Intro

You take pride in writing clean code...
You've passed all the technical interviews...
You've shipped features locally without breaking anything...
Then you attempt to deploy in a real AWS environment, and quickly get humbled.

If you’ve read my previous blog post about starting your first developer job in an AWS environment, then you know the moment I’m referring to. You log into the console at work and notice resources that existed long before you arrived, with names that look autogenerated and dashboards that are lighting up.

Then after a few weeks of getting comfortable, you try to deploy a feature or call an API for the first time, and you're stopped in your tracks by an AccessDenied error message.

You feel confused at first because nothing seems obviously wrong. Your code runs, your logic is sound and yet AWS still tells you, "you can't pass through!". That's when you learn the lesson that AWS operates on very strict rules around identity, permissions, configuration, quotas, and validation. It is extremely literal so if something does not meet its expectations exactly, it will reject the request.

Every developer, no matter how experienced, will stumble on AWS error messages so you're not going to avoid them entirely. However, in this blog, we're going to help you understanding what these error messages mean, how to both resolve them and reduce the chances of stumbling into them in the first place.

Now let's walk through these 5 common errors messages, AccessDenied, InvalidClientTokenId, ThrottlingException, ResourceNotFoundException and ValidationException.

AccessDenied (Nope! You're not allowed to do that!)

If there's one error message that will shape your first year working with AWS, it's the AccessDenied error message.

This error does not necessarily mean your code is syntactically wrong, or your logic is flawed. Actually, it means AWS fully understood what you asked it to do but intentionally rejected the request because your identity is not authorized to perform that action.

Most of the time, this traces back to Identity and Access Management. You might be trying to read from an S3 bucket, or invoke a Lambda function, or attach a role to a resource, but the IAM principal you're currently operating as does not have permission to perform that specific API action on that specific resource.

In more subtle cases, you might be in the wrong AWS account entirely, or targeting the wrong region and sometimes the missing permission is not obvious, such as iam:PassRole when a service needs to assume a role on your behalf.

When I first started working in real AWS environments, I thought an AccessDenied error message meant I'd made a personal mistake because I assumed I'd configured something incorrectly. Then, I later learned it was a deliberate guardrail my manager had set to limit what I could do in a specific AWS account, which was a good thing. In case you didn't know, most developers will never have full access to the AWS environment at their jobs.

When resolving an AccessDenied error, your first step is to confirm that you’re actually supposed to have access. Once that’s clear, your next question should be, "who am I right now?" In AWS, access is entirely based on identity, so before you assume the problem is a missing permission, you need to verify which principal is actually making the request. One of the fastest ways to answer that question is to ask AWS directly using the AWS CLI in your terminal:

aws sts get-caller-identity

That command returns the account ID and ARN of the user or role you’re currently authenticated as, immediately telling you whether you’re in the wrong AWS account, assuming an unexpected role, or using a different profile than you thought.

From there, you can ask more specific questions like, "Am I using the correct IAM role?", "Am I authenticated through the expected SSO profile?", or "Am I running this from my local machine, from a CI/CD pipeline role, or from within a Lambda function?" Each of those execution contexts has a completely different permission set, and many AccessDenied errors often result from operating in a context you didn’t intend.

From a reactive standpoint, the fastest way to debug AccessDenied error message is to read the full message carefully. AWS often includes the exact action that was denied and the ARN of the resource involved that tells you precisely which permission is missing. From there, you can inspect the attached IAM policies for your user or role and verify whether that action is allowed on that resource. If you're working in an organization with Service Control Policies, you may also need to check whether a higher-level restriction is blocking the action even if your local role appears correct.

So how can we limit AccessDenied errors so they don't slow you down?

One practical way is to design with least privilege intentionally instead of retroactively. When you're creating a new role for a service, take a few extra minutes to identify exactly which API calls it will need and grant those explicitly. If you're using infrastructure as code, strive to define IAM policies alongside your compute resources so permissions evolve with your application rather than lag behind it.

Another proactive habit is verifying your execution context before running critical operations. Make sure you get comfortable checking which AWS account and region you're currently in and confirming which IAM role your CLI profile or deployment pipeline is using because many AccessDenied issues are a result of operating in an unexpected environment.

InvalidClientTokenId (Yo! I don't know who you are)

InvalidClientTokenId usually shows up when you're working with the CLI, an SDK, or running code from your local environment. At first glance, this error message reads like something is fundamentally broken, but in reality, it's really straight forward.

It means the credentials attached to your request are either invalid, expired, or not the correct identity you think you're using.

Every AWS request is cryptographically signed so when you authenticate, AWS provides credentials that allow you to generate a signature proving who you are. That signature includes your access key and a timestamp and if the token is expired, malformed, revoked, or tied to access a different account than expected, AWS rejects the request immediately before even checking permissions. In other words, this is not about what you're allowed to do but whether AWS trusts who you are.

You’ll often see it surface in even the simplest SDK call:

import boto3

s3 = boto3.client("s3")
response = s3.list_buckets()
print(response)

If your credentials are expired or incorrect, AWS will respond with something like:

An error occurred (InvalidClientTokenId) when calling the ListBuckets operation:
The security token included in the request is invalid.

Notice that this happens before any permission evaluation because the request fails at the identity layer.

Early in my career, I lost more time to this error than I want to admit. I would question my app logic, inspect config files, and re-run deployments but eventually, I realized that whenever AWS complains about tokens, client identity, or security credentials, the problem is almost always contextual.

For a proactive debugging path, first confirm which AWS profile is currently active. If you're using AWS SSO, attempt to refresh your session. If you're using long-term credentials, confirm they haven't been rotated or invalidated and check for environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_PROFILE that may be overriding your expected configuration. If you're inside a container or CI/CD pipeline, verify which role is being assumed and whether it is still valid.

Another common scenario, is accidentally switching accounts. You might have authenticated successfully, but into the wrong AWS account. From the perspective of AWS, your token is valid, but not for the resources you're trying to access.

So before running critical commands, know exactly which identity you are operating as, be explicit about profiles instead of relying on defaults and in multi-account environments, make the current account visible in your prompt or logging output. As for CI/CD pipelines, try to surface the assumed role clearly in logs so it's not ambiguous which identity is making requests.

Lastly, always keep in mind that credential lifetimes are temporary credentials designed to expire so you'll intentionally need to build your workflows around refreshing sessions and not assume they'll last indefinitely.

ThrottlingException (Dude! Slow down!)

When you see a ThrottlingException or TooManyRequestsException error message, understand that AWS is enforcing limits to prevent you from overwhelming a system.

Every AWS service operates with defined quotas and internal protection mechanisms and these limits exist to preserve stability, fairness, and predictable performance across millions of customers. When your request rate exceeds what the service can handle at that moment for your account, AWS responds by throttling you.

New developers often hit this error message unintentionally because it's easy to write code that scales requests unintentionally, like a loop that calls an API hundreds of times per second or a Lambda function that scales concurrency faster than expected. In your local development, you rarely think about rate limits because everything runs in-process but in distributed systems, request pacing is an important part of the architecture.

When a ThrottlingException or TooManyRequestsException error message appears, the first question to ask is whether the throttling is burst-based or sustained. If it resolves quickly, you likely experienced a short spike but if it persists consistently, you may be exceeding configured quotas or overloading a particular resource.

The immediate instinct is often to retry immediately, but that can actually make the problem worse. The fix is to control retry logic using exponential backoff so requests slow down progressively instead of hammering the service.

Most AWS SDKs include retry logic automatically, but you should understand how it works and configure it intentionally when necessary. For example, in Python using Boto3, you can define retry behavior like this:

from botocore.config import Config
import boto3

retry_config = Config(
    retries={
        "max_attempts": 10,
        "mode": "standard"  # or "adaptive"
    }
)

dynamodb = boto3.client("dynamodb", config=retry_config)
response = dynamodb.list_tables()
print(response)

The standard mode applies exponential backoff, while adaptive adds client-side rate awareness. In short spikes, this can mean the difference between graceful recovery and cascading failure. When throttling persists consistently, however, it may indicate that you are exceeding a quota or that concurrency needs to be adjusted. Observability will play a critical role here for have visibility into what's actually happening. Some key metrics you'd want to monitor are, request counts, error rates, and service quotas so you understand whether you’re dealing with bursts or sustained pressure.

ResourceNotFoundException (That doesn’t exist. At least not here)

Few things are more confusing than seeing a resource clearly visible in the AWS Console while your application insists it doesn’t exist. When you encounter a ResourceNotFoundException, the instinct is often to assume AWS is contradicting itself. It usually isn’t.

AWS resources are almost always scoped to a specific region and account. If your Lambda function lives in us-east-1 and your CLI or SDK is configured for us-west-2, AWS is absolutely correct when it says the resource does not exist, because it does not exist in that region.

This is easy to miss in code. For example:

import boto3

lambda_client = boto3.client("lambda", region_name="us-west-2")

response = lambda_client.get_function(
    FunctionName="my-production-function"
)

If that function actually lives in us-east-1, this call will fail with ResourceNotFoundException. Simply being explicit about region can eliminate ambiguity:

lambda_client = boto3.client("lambda", region_name="us-east-1")

The same applies to account boundaries. A resource in one AWS account is completely invisible to another unless explicitly shared through mechanisms like cross-account access.

There are other subtle variations of this issue as well, for example, the ARN might be malformed or the resource ID contains a small typo. Other more nuanced causes are, a resource might been deleted and recreated with a slightly different identified or an application might be running in an execution context that doesn't have visibility into the resource even though it exists.

When you encounter the ResourceNotFoundException error message, resist the urge to immediately question AWS but instead, verify your context. Confirm the AWS account you're operating in, confirm the region config in your SDK or CLI, log the exact ARN or resource identifier being used in the request and check environment variables and configuration files to confirm they are pointing to the environment you expect.

One of the fastest debugging tips here is printing out the region and account identity at application startup. When something fails, you want immediate clarity about where you're operating from. Many “missing resource” errors are simply requests being sent to the wrong environment.

Additionally, try not to rely on defaults and ambiguous configurations that changes between development and production. In team environments, document which accounts and regions are responsible for which workloads and name resources in ways that make their environment obvious. When using multiple accounts, consider standardizing environment variables or deployment conventions so region and account targeting are always intentional.

ValidationException (Your input doesn’t meet the rules!)

ValidationException error messages show up across many AWS services and often feels frustrating because it can appear generic at first. However, they mean your request did not satisfy one or more of the service’s defined constraints.

AWS APIs operate on contracts and every operation has required parameters, allowed values, length limits, formatting rules, and structural expectations. If any part of your request violates that contract, the service rejects it immediately.

This could mean a required field is missing or an ARN is malformed, a numeric value exceeds an allowed range or even something as subtle as incorrect casing in an enumerated value. For example, consider creating a DynamoDB table:

import boto3

dynamodb = boto3.client("dynamodb")

response = dynamodb.create_table(
    TableName="Users",
    AttributeDefinitions=[
        {
            "AttributeName": "userId",
            "AttributeType": "STRING"  # Incorrect value
        }
    ],
    KeySchema=[
        {
            "AttributeName": "userId",
            "KeyType": "HASH"
        }
    ],
    BillingMode="PAY_PER_REQUEST"
)

In this case, STRING is invalid. DynamoDB expects S for string types. That small mismatch causes a ValidationException because the input does not match the expected schema.

A common mistake new developers make is not slowing down enough to read what the error message is clearly telling them. AWS is usually very explicit about what went wrong, like whether a required field is missing, a value doesn’t match the expected pattern, a data type is incorrect, or a maximum length constraint was exceeded.

To solve this error, you can examine the exact request being sent and compare it line by line with the official API documentation, confirm that required parameters are present and verify formats for ARNs and resource identifiers, double-check enum values and numeric limits and if you're using an SDK, log the final constructed request object to confirm it matches your expectations.

I believe it's worth checking whether your configuration has been modified by environment variables or defaults that differ across environments. A configuration that works in development may fail in production if a required parameter is missing or structured differently.

You should also treat infrastructure definitions and service configurations as strongly typed artifacts rather than loosely structured text. I strongly recommend using infrastructure-as-code tools that perform validation before deployment and linters or schema validation tools where possible to validate input early so malformed data never reaches AWS APIs.

Patterns Behind the Errors

As a new developer at your job, you might feel like you're constantly unexpectedly running into AWS error messages, but understand that this is all part of becoming more experienced in the cloud.

Overtime, you'll begin to notice that most error messages fall into the predictable categories of identity and authorization issues, permission boundaries, scope mismatches, validation failures, or scale constraints.

As you gain experience, your debugging process will become much calmer and structured instead of reactive and scattered because you'll be able to classify error messages into one of those buckets within the first few seconds.

I am curious to know though, which one of these AWS error messages trip you up the most or is the most frustrating to see?

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

Good luck!

If you've got this far, thanks for reading! I hope it was worthwhile.

Everything You Need to Know About AWS for Your First Developer Job

Ifeanyi O. — Tue, 10 Feb 2026 11:12:37 +0000

A real-world guide for day-one developers

Intro
Your First Surprise
AWS Categories
Your Terminal Is Important
It Already Existed
Think Serverless
Changes in Prod
Observe Before You Optimize
Cost Will Show Up
Structure from Certifications
What Really Matters

Intro

You just landed your first developer job! Congratulations!

You’re excited, proud and already imagining what it’ll be like to finally build things for real, not just for personal projects and experimentation.

Day one comes around, you open your new company laptop, join a few team channels, and begin receiving access to an AWS account, or maybe several.

You notice pipelines you didn’t create, services you recognize by name but not by behavior and permissions you don’t fully understand.

You might even see things like Amazon S3 buckets, AWS Lambda functions, Amazon API Gateway endpoints, Amazon CloudWatch dashboards, and a few AWS IAM roles with names that look like they were created by someone in a hurry.

And that’s when it hits you. You didn’t actually know what to expect.

You want to do well and increase the possibility of ramping up quickly to make a good impression and avoid being the person who breaks something important or feels lost for weeks. You start asking yourself, what should you already know, what should you focus on first, and how do people actually work with AWS day to day.

Don’t worry, I’ve got you! This post is for that moment.

This post is for developers preparing to start their first job working with AWS and trying to figure out how to be ready before and after day one. We’ll go beyond theoretical and lean into what’s practical.

We'll tackle what to understand, what to pay attention to, and what should be running in the back of your mind as you start working inside a real company's AWS environment.

Your first surprise comes quickly

One of the first thing you'll notice is that AWS at your job feels very different from the AWS environment you learned tutorials and built projects in.

A mental shift that helps is realizing you didn’t get hired to “learn AWS” in the abstract. There’s no clean starting point. There's no empty account waiting for you to build the “right” architecture. Instead, you’re stepping into an already existing system that includes, accounts, environments, pipelines, permissions, processes, conventions. All of it built for reasons you don’t fully understand yet.

AWS is vast. There are more than 200 services, which is exciting but as a first time developer, can be annoying at the same time. The good news is that most teams don’t use them all. In day-to-day work, AWS usually shows up in a few main technical areas like compute, storage, networking, security, databases, analytics, artificial intelligence, machine learning, observability, and deployment tooling. If you learn how your team uses those areas, the rest starts to feel manageable.

It’s easy to feel behind here. A lot of new developers assume everyone else knows what’s going on and they’re the only one catching up. That assumption is almost always wrong! What matters early is not how much you know but how well you learn the shape of the system you just joined.

AWS categories you need early

It helps to mentally group AWS into the big categories developers actually work in.

Compute is where code runs. This could be AWS Lambda for serverless functions, Amazon EC2 for virtual machines, or containers on Amazon ECS or Amazon EKS. Storage is where files and artifacts live, usually in Amazon S3. Databases hold application state, commonly stored in Amazon DynamoDB or Amazon RDS. Networking is how services connect and communicate safely, which is where Amazon VPC, subnets, security groups, and load balancers like an Application Load Balancer show up. Security sits across everything through Amazon IAM, AWS KMS, and network boundaries. Observability is how you see what’s happening in your systems in production through services like Amazon CloudWatch and AWS X-Ray, and audit trails like AWS CloudTrail.

You absolutely do not have to master all of these in week one, you just want enough familiarity to recognize what you’re looking at so you can ask more effective questions.

You're stepping into your company's AWS environment, not a lesson plan

Know that you got hired to work inside a specific AWS environment that already supports real users and real business needs.

Your immediate objective is to understand how things work well enough to change them without causing damage, how code gets deployed, how services talk to each other, how failures are noticed and handled and how access is controlled.

A simple but powerful habit in your first week is getting clarity on where you are. Answer questions like, which AWS account are you in, which region are you in, are you in a development, staging, or production environment.

AWS Regions and Availability Zones matter because they shape latency, resilience, and where resources physically live. If you hear someone say “this is in us-east-1” or “that workload is multi-AZ,” they’re not trying to test your alphanumeric understanding, they're just giving context to where and how resources are deployed.

When I made my own transition into tech from a completely different career, this took time to sink in. Before the cloud, I was a professional athlete. Progress in that career, came from understanding the system you were competing in and improving inside it. AWS turned out to be similar. Once I stopped trying to know everything and started trying to understand the environment I was in, the learning curve flattened out.

Your terminal becomes important very fast

Early on, you’ll probably write less code than you expected. That’s normal!

Most of your first week is about setup. Getting your local environment working the way your team expects. Installing the AWS CLI. Understanding how authentication works at your company. Maybe it’s AWS IAM Identify Center for Single Sign-On (SSO), maybe it’s using temporary credentials through AWS Security Token Service or maybe it’s multiple CLI profiles tied to different accounts.

However it’s done, you want to understand how requests from your laptop become actions in AWS. That clarity makes debugging easier and gives you confidence when something doesn’t work.

The AWS Console is useful, especially when you’re new but the terminal is where most developers spend their time once they’re comfortable. It’s faster, repeatable, and closer to how things actually run in automation.

Permissions are usually the problem

At some point, something will fail in a way that doesn’t make sense. Your code looks right. The resources exist. You'll try it again and receive the same result.

This is usually where permissions enter the picture. Permissions is one of the first debugging steps to check when you’re receiving errors while trying to read or change resources.

Identity and access controls are at the center of AWS, and they trip everyone up early on. A lot of issues aren’t logic errors at all but they’re actually boundaries set that are doing exactly what they’re supposed to do. In real environments, you’ll run into IAM roles and policies, resource-based policies like Amazon S3 bucket policies, and sometimes encryption rules enforced through AWS KMS.

Once you start thinking in terms of who is making a request, what they’re allowed to do, and which resource is involved, AWS permissions becomes easier to reason about. Treating IAM as a core skill early, and learning to recognize permission failures will quickly save you a lot of debugging frustration.

Most of what you touch already existed before you arrived

At your new job, you will inherit infrastructure before you will design anything new.

That infrastructure is usually defined as code using Infrastructure as Code (IaC) tools like AWS CloudFormation, AWS CDK or Terraform. These tools allow infrastructure to be versioned, reviewed, and deployed like application code. Even if you’re not writing it yet, learning how to read it matters!

You’ll also start noticing where that infrastructure connects to delivery workflows. If your team uses AWS CodePipeline and AWS CodeBuild, or even a mix like GitHub Actions plus CloudFormation, then these are the path your developer changes will follow.

Being able to tell what will change before it changes is how teams avoid breaking production. Developers who take the time to understand existing infrastructure build trust quickly because they’re showing respect for the system.

Serverless may force you to change how you think

There’s a good chance your new role involves serverless, and that’s another adjustment.

You will have to pause to stop thinking primarily about servers and start thinking about triggers and events. For example, an API request comes into Amazon API Gateway and invokes an AWS Lambda function, a file upload lands in Amazon S3 and triggers processing, a message arrives in Amazon SQS or Amazon SNS and kicks off work, an event is routed through Amazon EventBridge, a workflow spans multiple steps using AWS Step Functions and an application’s state that lives in Amazon DynamoDB.

This mindset will affects how you write code and how you handle failure. You'll start caring about retries, idempotency, and visibility earlier because distributed systems fail in messy ways. You'll also start thinking about scalability differently because serverless services scale automatically, but they still have limits and concurrency behaviors you need to understand.

Learn how changes reach production before making one

Before you ship anything meaningful, it helps to understand how a change actually makes it to production.

Figure out what starts the deployment process. Learn whether approvals are needed. Understand how environments are separated. Ask what happens when something fails and how rollbacks are handled.

If your team uses AWS CodePipeline, GitHub Actions, GitLab or a Git-based workflow, watch a few deployments go through before you touch anything major. This will be critical to understand because when things go wrong, the calmest developers are usually the ones who understand the delivery system.

Knowing this upfront will keep you from guessing later, and make you calmer when you do ship your first change.

Observe before you optimize

Production systems don’t always announce problems clearly. Logs, metrics, and traces are how you will figure out what’s happening when you’re not watching. In serverless environments especially, they’re your only way to real visibility.

You’ll likely spend time in Amazon CloudWatch Logs and Metrics, and in some environments you’ll also use AWS X-Ray for tracing. When someone asks “who changed this,” that’s where AWS CloudTrail becomes useful because it shows all API activity to help you understand what happened.

Spending time early just observing how systems behave helps you build intuition. Over time, you start to recognize what normal looks like, which makes it easier to spot when something isn’t.

Cost will show up sooner than you expect

It’s better to learn this early because contrary to the tutorials you’ve done, developing on AWS at your job is not purely technical. There’s an economic side to operating in the cloud that directly affects your company’s business.

Every decision has a cost attached to it. You don’t need to be perfect about this early on, but you should be aware. Leaving things running, misconfiguring resources, or forgetting to cleanup adds up quickly. In most teams, you’ll use AWS Cost Explorer and AWS Budgets, and some will rely on the Cost and Usage Report for deeper reporting. Tagging resources also matters more than people expect because it’s how teams attribute cost to systems and owners.

Developers who pay attention to cost tend to think more carefully about trade-offs, and that mindset shows maturity. It also signals that you understand you’re building for a business, not just for a demo.

Certifications can help if you want structure

You don’t need a certification to be successful in your first AWS developer job. Plenty of great developers never pursue one. That said, certifications can be genuinely useful when you’re feeling overwhelmed and want a structured way to build familiarity with AWS and how things fit together.

The real value is often in the process of studying, not the exam itself. Preparing for an AWS certification forces you to slow down and learn how AWS expects systems to be build and architected well.

During this process, you'll start to see recurring patterns around compute, networking, security, storage, scalability, and fault tolerance. You'll also begin to understand why certain services are paired together and why some designs are preferred over others. That kind of exposure helps you develop better instincts long before you’re asked to design anything on your own on the job.

If you’re early in your journey and want a broad foundation, the AWS Certified Cloud Practitioner can help you build vocabulary and basic cloud context. It introduces you to core services, shared responsibility, pricing concepts, and the global nature of AWS without going too deep too fast.

If you want to go a level deeper into what you’ll actually see in a developer role, the AWS Certified Developer Associate and the AWS Certified Solutions Architect Associate certifications are a natural next steps.

The AWS Solutions Architect Associate focuses on how systems are designed on AWS as a whole. You spend time thinking about cost efficiency, performance, reliability, and scalability. You learn how different services work together and how architectural decisions affect long-term outcomes. For many, this certification is where AWS stops feeling like a collection of isolated services and starts feeling more cohesive.

Studying for the AWS Developer Associate exposes you to how applications are built and deployed on AWS. It includes topics like serverless development, CI/CD workflows, monitoring, and troubleshooting, which will help you understand how code behaves once it leaves your laptop and runs in AWS.

These certifications are accelerators for learning and will help you stay oriented while you’re building experience, but know that they are not the destination. You can always look into pursuing many other AWS or industry certifications offered but remember, the magic only happens when you apply those concepts on the job, one change, one system and one debug session at a time.

Expectations and what really matters

For your first AWS developer job, you're not expected to be an expert. Early success looks like learning how to operate inside a complex system, asking good questions, making safe changes, understanding impact, and improving steadily.

That approach is what helped me move from a completely different career into cloud development, and it’s what I’ve seen work consistently for others. Your journey of a new developer on AWS will depend on how you take the time to understand the environment you’re working in.

If you do that, you’ll ramp up faster than you think and set yourself up for everything that comes next.

Lastly, if you're looking to dive deeper in your learning journey, explore these FREE AWS resources:

Good luck!

If you've got this far, thanks for reading! I hope it was worthwhile.

Forem: Ifeanyi O.

Amazon S3 Files Is Still Not A File System

Table of Contents

Intro

So what is S3 Files?

What changed for developers

How S3 Files works at a high level

Why this matters for AI

Practical code example

Security and operational details worth noting

Key takeaways for developers

5 AWS Services New Developers Struggle With (And Why)

Table of Contents

Intro

IAM

VPC

SQS vs SNS

CloudFormation

CloudWatch

Why These Five Services Matter

5 Common AWS Errors New Developers Hit (And How to Fix Them)

Table of Contents

Intro

AccessDenied (Nope! You're not allowed to do that!)

InvalidClientTokenId (Yo! I don't know who you are)

ThrottlingException (Dude! Slow down!)

ResourceNotFoundException (That doesn’t exist. At least not here)

ValidationException (Your input doesn’t meet the rules!)

Patterns Behind the Errors

Everything You Need to Know About AWS for Your First Developer Job

Table of Contents

Intro

Your first surprise comes quickly

AWS categories you need early

You're stepping into your company's AWS environment, not a lesson plan

Your terminal becomes important very fast

Permissions are usually the problem

Most of what you touch already existed before you arrived

Serverless may force you to change how you think

Learn how changes reach production before making one

Observe before you optimize

Cost will show up sooner than you expect

Certifications can help if you want structure

Expectations and what really matters