CCHQ ARTICLE GUIDE / CLOUD PLATFORMS
Practical learning, clear decisions, real-world context
An easy-to-navigate technical field guide with key takeaways, actionable checks, FAQs, and official references. Approximately 7 minutes of reading.
The core AWS services every cloud engineer should understand are not simply the most recognizable logos on an architecture diagram.
They are the services that explain how workloads authenticate, communicate, run code, store data, recover from failure, and reveal what is happening in production.
For most learners, that means IAM, VPC, EC2, Lambda, S3, databases, CloudWatch, CloudTrail, and the services that connect them. You do not need to memorize hundreds of products to be productive.
You need to understand a few foundational service families deeply enough to design a safe workload, predict its failure modes, and troubleshoot it under pressure.
This guide follows an example web application through its service dependencies and shows what to learn, what to verify, and where inexperienced teams often get into trouble.
At a glance
The main topics you’ll work through:
- IAM: identity comes before infrastructure
- VPC: how workloads communicate
- EC2 and Lambda: two different compute models
- S3: durable object storage with deliberate access
In this guide
01 / KEY CONCEPT
IAM: identity comes before infrastructure
KEY TAKEAWAY
AWS Identity and Access Management determines which principals can perform which actions against which resources under which conditions.
In a modern environment, human administrators should generally use federation and temporary credentials; workloads should use IAM roles rather than embedding access keys in source files.
A role’s trust policy controls who can assume it, while permission policies control the actions allowed after assumption. Service control policies and permissions boundaries can provide additional guardrails, but they do not independently grant access.
For a beginner lab, create a deployment role with only the permissions your project needs. Then make a separate application role that can read exactly one protected object or write to one designated log group.
Check failed requests instead of solving every access error by attaching an administrator policy. AWS IAM Access Analyzer can help refine privileges based on activity, but generated policy suggestions require review.
A cloud engineer who can explain an AccessDenied event and evaluate an identity path is developing a foundation relevant to every AWS service.
02 / PRACTICAL APPLICATION
VPC: how workloads communicate
KEY TAKEAWAY
Amazon Virtual Private Cloud defines network boundaries for many AWS compute and database workloads.
Subnets place resources into address ranges and availability zones; route tables influence where packets go; security groups filter traffic to attached resources. Network ACLs provide another subnet-level control.
Internet gateways, NAT gateways, and VPC endpoints serve different connectivity purposes and have different operational and cost implications. Do not assume that using a so-called private subnet eliminates every external path or makes all workloads safe.
Build a two-tier network diagram with a public entry point and an application component whose database is not directly reachable from the internet. Trace the full path from a visitor to the app and from the app to a private database.
Then trace outbound traffic for package updates and AWS APIs. Identify where you need VPC endpoints or a NAT path. Validate security group references, DNS resolution, and route tables before troubleshooting the application code.
Many apparent application bugs are actually routing or permission misunderstandings.
03 / KEY CONCEPT
EC2 and Lambda: two different compute models
KEY TAKEAWAY
Amazon EC2 provides virtual machines with control over the guest operating system and application runtime.
It can be appropriate for specialized software, persistent server processes, or workflows requiring OS-level customization. That control creates responsibility for patching, host hardening, storage, scaling, monitoring, and instance replacement.
Lambda runs functions in response to requests or events without requiring you to maintain guest servers directly.
It can simplify short-lived, event-driven processing, although function limits, cold-start behavior, packaging, concurrency, and dependencies still matter.
To compare them, implement a trivial HTTP endpoint conceptually and list the work involved. With EC2, you choose an image, instance type, network interface, instance role, patching approach, and process supervision.
With Lambda, you configure permissions, invocation, timeouts, integrations, logs, and deployment artifacts. Neither option eliminates the need for authentication, deployment discipline, testing, or cost awareness.
Prefer the simpler fit for the workload rather than choosing one compute model because it is fashionable or appears on a certification roadmap.
04 / PRACTICAL APPLICATION
S3: durable object storage with deliberate access
KEY TAKEAWAY
Amazon S3 stores objects in buckets and is widely used for static assets, backups, logs, and application files.
A bucket is not a network disk; applications interact using object operations and an access model shaped by IAM, bucket policies, ownership settings, and other controls.
Modern S3 supports encryption by default, but that does not replace careful authorization or data classification. Block Public Access helps prevent public bucket exposure and is a sensible default for private application data.
For a learning exercise, create a private bucket, upload one non-sensitive object, and authorize a specific application role to read only the required path. Test the allowed read and an intentionally disallowed action.
Enable versioning if recovery from accidental object changes is part of the goal, and consider lifecycle policies because previous versions and log objects can accrue charges.
If you need public content delivery, design the public access path deliberately through an appropriate service instead of simply making an entire bucket public.
05 / KEY CONCEPT
Databases: pick by access pattern and recovery goal
KEY TAKEAWAY
AWS offers managed relational, key-value, document, analytics, and other database options.
A relational database is suitable when the data model relies on transactions and relationships; a key-value database can be effective for known access patterns and predictable key-based queries.
A managed database reduces some infrastructure work but does not take over schema design, IAM strategy, network isolation, data retention, or application correctness.
A database’s availability model also does not automatically equal a complete backup and restore policy.
Start by listing the five queries your application needs most. Decide what data must be consistent after a failed write, whether you need joins, and what a recovery point objective would mean for users.
Then compare a managed relational service and a managed NoSQL service against those needs. Include storage, backups, request charges, throughput provisioning, and network dependencies in the cost discussion.
The right choice comes from the workload’s data behavior, not from guessing which AWS database is most popular.
06 / PRACTICAL APPLICATION
CloudWatch and CloudTrail: operating with evidence
KEY TAKEAWAY
Amazon CloudWatch supports metrics, logs, dashboards, and alarms that help engineers observe workloads.
AWS CloudTrail captures account activity and API events for auditing and investigation, subject to the configured trails and event selectors.
An application can fail even when the virtual machine is running; a metric, a structured log, and a trace often reveal different parts of the same problem.
Define a small set of indicators around user impact, such as request failure rate, latency, and successful processing.
During a lab, deliberately trigger an invalid input and confirm that the error appears in application logs without exposing secrets. Review the role assumed by the application and find relevant management events through CloudTrail where available.
Keep logs useful and finite: retention, high-cardinality custom metrics, and verbose debug output can create unnecessary costs.
Monitoring is only operationally valuable when someone knows how to interpret the signal and what action to take when a threshold is exceeded.
07 / KEY CONCEPT
Other service families worth recognizing
KEY TAKEAWAY
Route 53 provides DNS functions; Elastic Load Balancing distributes certain traffic types; CloudFront helps deliver content closer to readers; API Gateway can front APIs; ECS and EKS orchestrate containers; EventBridge, SQS, and SNS support event-driven integration patterns.
KMS helps manage encryption keys, while Secrets Manager supports credential and secret management. Systems Manager provides operational capabilities that can reduce the need for direct host login.
Learn the purpose of each service family before memorizing product-specific configuration pages.
A strong cloud engineer recognizes when adding a service reduces complexity and when it multiplies dependencies.
For example, a queue can decouple slow work from a synchronous web request, but it also introduces retry, duplicate-processing, and monitoring questions. A load balancer may improve availability and routing, but it adds costs and security considerations.
The engineering task is to understand the complete path and decide which components are justified. Build with the smallest set that satisfies requirements, then revisit the design after observing real workloads.
08 / PRACTICAL APPLICATION
A security-first practice project
KEY TAKEAWAY
Design a small application with one authenticated API, one private object storage location, and centralized logs.
Use IAM roles rather than embedded credentials, route administrative access separately from public traffic, and store deployment configuration in version control without secrets.
Set an AWS budget alert before provisioning and tag resources so you can identify the lab later. Begin by drawing the identity and network paths and writing a teardown checklist.
Even a minimal project should document the intended security boundary and how to inspect it.
Run a few checks once resources are deployed: can the app perform only its necessary S3 action, does an unauthorized call fail, do you have logs for the rejected request, and can you identify the resource costs?
Then remove a dependency in a nonproduction experiment and observe the expected error. Record what you actually saw, not what a tutorial claims should happen. This makes a much more credible portfolio entry than a screenshot of a green status icon.
Before you finish: practical checklist
Turn the main lessons into a short review of your own environment:
- Check failed requests instead of solving every access error by attaching an administrator policy.
- Build a two-tier network diagram with a public entry point and an application component whose database is not directly reachable from the internet.
- Identify where you need VPC endpoints or a NAT path.
- Test the allowed read and an intentionally disallowed action.
- Start by listing the five queries your application needs most.
Frequently asked questions
Do I need to learn every AWS service?
No. Learn core service families, the relationships between them, and how to find current official documentation. Specialize later based on your role.
Is Lambda always cheaper than EC2?
No. Different traffic patterns, execution duration, integrations, and supporting resources change the bill. Compare total workload costs rather than one rate.
Which service should I learn first?
Start with IAM and billing guardrails, then VPC and S3, then a compute service. That order makes early experiments safer and helps explain failures instead of bypassing protections.
Official documentation and next step
AWS IAM best practices · Amazon S3 security · AWS Well-Architected · AWS Budgets pricing and alerts
Continue with the Cloud Platforms guides and choose a single workload to develop. Learn how a request crosses IAM, network, compute, storage, and observability boundaries.
The core skill is explaining the dependency chain, then proving that the security, logging, and recovery decisions behave as intended.
