Search
30 results for “aws”
Search results
AWS CloudWatch & CloudTrail
How CloudWatch metrics, logs, and alarms fit together with CloudTrail's audit trail, and why CloudTrail answers "who did what" while CloudWatch answers "what is the system doing."
AWS Compute
How EC2, Lambda, ECS, and EKS trade control for convenience differently, and how to actually choose between them instead of defaulting to whichever one you already know.
AWS IAM
How IAM users, roles, and policies control access in AWS, why roles with temporary credentials are preferred over long-lived access keys, and how policy evaluation actually decides allow versus deny.
AWS Organizations & Account Structure
How AWS Organizations, organizational units, and the AWS account itself form the real isolation boundary, and why that structure - not any single resource - is where governance and billing actually happen.
AWS Storage
How S3, EBS, and EFS fit different access patterns, what S3 storage classes actually trade off, and why durability and availability are two different numbers.
AWS VPC Networking
How Amazon VPC, subnets, security groups, and network ACLs control traffic in AWS, and why security groups (stateful, instance-level) and network ACLs (stateless, subnet-level) are not interchangeable.
AWS Cloud Engineer Roadmap
From the AWS account structure through identity, networking, compute, storage, and monitoring, the core path for a working AWS engineer, linked into Cloud Tech by Victor topic references.
When would you choose AWS Lambda over EC2 for a workload?
Lambda fits event-driven, short-lived work, an API request, a file landing in S3, a queue message, where you want to pay only for actual invocation time and never manage a server at all; a function can run for at most 15 minutes and has no state between invocations. EC2 fits workloads that need to run continuously, need OS-level control, exceed Lambda's execution-time or memory ceiling, or need to retain in-process state between requests. The decision is about execution model and constraints, not maturity, a long-running stateful service is a worse fit for Lambda regardless of how "serverless-first" a team wants to be.
What is the fundamental unit of isolation in AWS, and how does that differ from a single resource-group boundary in Azure?
In AWS, the account itself is the fundamental security and billing isolation boundary, every resource lives inside exactly one account, and account-level separation is what actually contains blast radius (a compromised credential in one account cannot directly touch resources in another). This differs from Azure, where a single subscription can contain many resource groups as an additional lifecycle boundary beneath it. AWS has no equivalent nested container inside an account for "delete everything in this group together," which is why multi-account strategies (via AWS Organizations) do the job that resource groups partly do in Azure, at the account level instead of a sub-account level.
Why would an organization use multiple AWS accounts instead of one account holding all resources?
Separate accounts per environment (production, staging, development) or per team give a hard isolation boundary that a single account with tags or naming conventions cannot: a mistake or compromised credential in a development account cannot reach production resources at all, rather than merely being restricted by IAM policy within the same account. It also gives cleaner cost attribution (billing rolls up per account), independent service quotas, and a natural blast-radius limit for security incidents. AWS Organizations, and patterns built on top of it like a landing zone, exist specifically to make many accounts manageable, centralized billing, centralized logging, and org-wide SCPs, without losing that isolation.
What is the difference between CloudWatch and CloudTrail?
CloudWatch is the operational observability platform: metrics, logs, dashboards, and alarms that answer "what is the system doing right now," CPU usage, request latency, error rates, application log output. CloudTrail is the audit trail of AWS account activity: a record of API calls and console actions that answers "who did what, when, from where," regardless of whether that action succeeded, failed, or even touched application behavior at all. They are frequently confused because both involve "logs," but CloudWatch Logs holds whatever an application or service chooses to emit, while CloudTrail holds a record of AWS API calls themselves, and neither substitutes for the other.
What is the difference between CloudTrail management events and data events, and why does it matter?
Management events record control-plane operations, creating a role, launching an instance, changing a security group, and every CloudTrail trail logs these by default. Data events record data-plane operations on the resources themselves, an individual S3 GetObject or Lambda Invoke call, and are not logged by default; they have to be explicitly enabled per resource and typically cost extra given their much higher volume. This matters because an investigation into "who read this specific S3 object" will come up completely empty if only the default management events were ever being logged, a genuinely common gap discovered only during an actual incident.
When would you use a CloudWatch alarm versus digging into CloudWatch Logs Insights?
A CloudWatch alarm watches a metric against a threshold and is the right tool for fast, simple, near-real-time detection, error rate crossing 5%, latency crossing a p99 target. CloudWatch Logs Insights is a query language for ad hoc investigation of the underlying log data, the tool for answering a specific question an alarm was never built to ask, like "which requests failed, and what did they have in common." Alarms are for detecting that something is wrong quickly; Logs Insights is for actually finding out why once an alarm (or a user report) says something is.
What is the difference between ECS and EKS?
Both are managed container orchestrators, but ECS is AWS's own native orchestration model (task definitions, services, clusters) with no separate control-plane fee, while EKS runs an actual, standard, upstream Kubernetes control plane that AWS manages for you, and Amazon EKS charges a per-cluster fee specifically for that managed control plane, on top of whatever compute the worker nodes cost. Both can run workloads on EC2 instances you manage, or offload node/workload compute to AWS via Fargate or, on EKS specifically, EKS Auto Mode, so "serverless containers" is available either way; the real choice is whether you want Kubernetes's API and ecosystem (EKS) or a simpler, AWS-native model with less portability (ECS).
What does an EC2 Auto Scaling Group actually manage, and why does the scaling metric choice matter?
An Auto Scaling Group keeps a fleet of EC2 instances at a desired size, launching or terminating instances automatically based on configured scaling policies, and replacing instances that fail health checks, so nobody is manually adding or removing servers as load changes. The scaling metric determines whether that automation actually tracks the real bottleneck: scaling purely on CPU utilization looks like "autoscaling is working" on a dashboard while a memory-bound or queue-depth-bound workload keeps falling behind, because the metric driving the scaling policy never reflected the actual constraint. Choosing a metric (or combination of metrics, including custom CloudWatch metrics) that matches the workload's real bottleneck is what makes the automation actually correct rather than just present.
What is the difference between an IAM user and an IAM role?
An IAM user is a long-term identity with its own credentials, a password for console access, or access keys for programmatic access, typically representing a human or a legacy application that needs standing access. An IAM role has no long-term credentials of its own; it is assumed, by a user, an application, or an AWS service, and yields short-lived, automatically-expiring temporary credentials via AWS STS. Roles are the preferred identity for anything running on AWS compute (EC2, Lambda, ECS) precisely because there is no long-lived secret to leak or rotate.
How does IAM decide whether a request is allowed, and what wins if there is a conflict between an Allow and a Deny?
IAM evaluation starts from an implicit deny, nothing is allowed unless some applicable policy explicitly allows it. It then checks every applicable policy for an explicit Deny; if one exists anywhere, identity-based, resource-based, a permission boundary, an SCP, or an RCP, the request is denied regardless of how many Allow statements also apply. Beyond that, identity-based and resource-based policies are the only policy types that actually grant permissions, an Allow from either is required. Permission boundaries, SCPs, and RCPs never grant anything themselves, they only cap what a grant can reach, so the request also needs every applicable one of those to independently allow the action; any one of them failing to allow it denies the request even with a valid Allow in place. An explicit Deny always wins over an explicit Allow, no matter which policy or how specific the Allow is.
Why are IAM roles preferred over long-lived access keys for workloads running on EC2 or Lambda?
A long-lived access key is a static secret that must be stored somewhere, an environment variable, a config file, a secrets manager, and rotated manually or via automation; if it leaks, it remains valid until someone notices and revokes it. An IAM role attached to an EC2 instance profile or a Lambda execution role is assumed automatically by the AWS SDK, yielding short-lived credentials that are rotated transparently and expire on their own even if never explicitly revoked. This removes the entire class of "leaked long-lived credential" risk for workloads that run on AWS compute, which is why roles are the default recommendation over access keys whenever the workload runs inside AWS.
What is a Service Control Policy (SCP), and what is the one thing it does not do?
An SCP is a policy attached to an AWS Organizations root, organizational unit, or member account that defines the maximum available permissions for every identity in that account, including that account's own administrators and its root user. What an SCP does not do is grant any permission by itself, it only sets a ceiling; an identity still needs an actual IAM allow (from an identity-based or resource-based policy) within that ceiling to do anything. An SCP with no matching IAM allow underneath it results in access denied, not access granted, which is the most common misunderstanding of how SCPs work. One exception worth knowing: SCPs never apply to the organization's management account itself, only to member accounts.
What is the difference between S3, EBS, and EFS?
S3 is object storage accessed entirely through an HTTP(S) API, not mounted as a filesystem, built for unstructured data at virtually unlimited scale. EBS is block storage that attaches to exactly one EC2 instance at a time (Multi-Attach for io1/io2 is the narrow exception) and must live in the same Availability Zone as that instance, functioning as its persistent virtual hard disk. EFS is a fully managed NFS file system that is regional by default, replicated across multiple Availability Zones, and can be mounted concurrently by many instances at once. The choice comes down to access pattern: S3 for API-driven object access, EBS for a single instance's own low-latency block storage, EFS for a shared network file system across many instances.
What is the difference between durability and availability in S3, and why does it matter when picking a storage class?
Durability is the probability that a stored object is not lost over a year, and S3 Standard, Standard-IA, and every Glacier class are all designed for the same 99.999999999% (11 nines) durability. Availability is how often the object can actually be successfully retrieved on demand, and that number does vary by class, 99.99% for Standard down to 99.5% for One Zone-IA. It matters because a cheaper class is not automatically a less durable one, S3 One Zone-IA is exactly as durable as Standard-IA per object, but it is not resilient to the loss of its single Availability Zone at all, since it isn't replicated across multiple zones the way every multi-AZ class is.
Why would you use EFS instead of EBS for a given workload?
EBS attaches to a single EC2 instance and lives in one Availability Zone, which is exactly right for a database's own local-feeling disk but doesn't work at all when more than one instance needs to read and write the same files concurrently. EFS is designed for exactly that case: a regional, NFS-mountable file system that many EC2, ECS, or Lambda-backed clients can mount and use at the same time, with strong consistency across them. The trigger for reaching for EFS instead of EBS is almost always "does more than one compute resource need to share this data," not a performance decision alone.
What is the difference between a security group and a network ACL in a VPC?
A security group is stateful and attaches at the instance/ENI level: it only supports allow rules, and if inbound traffic is allowed, the corresponding response traffic is automatically allowed back out regardless of outbound rules. A network ACL is stateless and attaches at the subnet level: it supports both explicit allow and explicit deny rules, numbered and evaluated in order starting from the lowest number, and because it has no memory of prior traffic, allowing inbound traffic does not automatically allow the matching outbound response, that has to be permitted by its own rule. Security groups are the primary, fine-grained access control per resource; network ACLs are a coarser, optional second layer at the subnet boundary.
If VPC A is peered with VPC B, and VPC B is peered with VPC C, can A reach C through B?
No. AWS VPC peering connections are explicitly non-transitive: a peering connection is a strict one-to-one relationship between exactly two VPCs, and you cannot use one VPC as a transit point for another peering connection it happens to also have. To let A reach C, a separate, direct peering connection between A and C has to be created; there is no way to route through B. A Transit Gateway, not a mesh of peering connections, is the AWS-recommended way to connect more than a couple of VPCs that all need to reach each other.
What is the difference between a public and a private subnet in a VPC?
The difference is entirely about the subnet's route table, not any property of the subnet itself: a public subnet has a route to an internet gateway for `0.0.0.0/0`, so resources with a public IP in it can reach and be reached from the internet directly. A private subnet has no such route, so its resources typically use a NAT gateway (in a public subnet) for outbound-only internet access, or no internet path at all. Both subnet types can otherwise have identical security group and NACL configuration; "public" and "private" describe reachability via routing, not a separate networking feature.
Cloud Computing Explained: Models, Architecture, Security, and Real-World Use
Modern businesses rely on technology to operate, scale, and compete. Traditionally, this meant running physical data centers filled with servers, networking equipment, and storage systems. While this on premises approach offers control, it also introduces high upfront costs, ongoing maintenance, an…
Rate Limiting Algorithms
How the token bucket algorithm AWS API Gateway actually uses separates a steady-state rate from a burst allowance, and why a request only fails once the bucket is genuinely empty, not the instant the average rate is exceeded.
What is Terraform state and why is it required?
State is a JSON file (by default `terraform.tfstate`) that maps every resource block in your configuration to the real-world object Terraform created for it (an AWS instance ID, a DNS record, etc.). Terraform is declarative, your config describes the desired end state, not the steps to get there, so on every run it needs state to compute a diff between what exists now and what the config says should exist. Without state, Terraform would have no way to know whether a resource already exists, needs updating, or was deleted outside of Terraform.
Why does a real ring hash implementation give each host many positions on the ring instead of just one, and what problem would a single position per host cause?
A host thrown onto the ring at just one point can end up, purely by chance, owning a disproportionately large or small arc of the ring if the hash values happen to land unevenly, since with few points there's no averaging effect smoothing out the randomness. Assigning each host many positions on the ring, scaled by that host's intended weight, so a double-weight host gets roughly twice as many ring entries as a single-weight one, averages out that randomness across many smaller arcs per host, producing a much more even overall traffic distribution than a single coin-flip-like placement per host would.
A transaction under Repeatable Read isolation fails with "could not serialize access due to concurrent update." What actually happened, and what is the application expected to do?
Repeatable Read uses snapshot isolation, the transaction sees a consistent snapshot from its own start, but if it then tries to update a row that another, concurrently-committed transaction already modified, PostgreSQL detects the conflict and aborts the transaction with a serialization failure rather than silently applying an update based on stale data. This is not an application bug, it is Repeatable Read (and Serializable) working as designed, both isolation levels explicitly require the application to catch this specific error and retry the transaction from the beginning, trading the guarantee of not overwriting concurrent changes for the operational cost of occasional automatic retries.