This is the start of my study notes for the AWS Certified Cloud Solutions Architect, Associate.
I had previously passed the Cloud Practitioner exam, which was enough to give me a sense of what AWS offers.
Foreword
Most AWS documentation is product-oriented, which means the user guides are written for a specific service.
This can make understanding AWS difficult because many AWS services have different paradigms compared to each other.
For example, S3 has a weird concept of a bucket ACL which controls access to the bucket. This “ACL” is not used in any other service except for S3. Every other service uses IAM policies to control access.
AWS services have these odd disconnects because AWS has existed for a relatively long time and is required to have a stable API. Just like any other software, AWS services were built by different teams, accumulated technical debt, and passed between multiple developers over its lifetime. Because AWS has a strong promise to maintain API stability, the service developers cannot refactor these services to make them consistent.
Thankfully, there are still many common aspects shared between services, resources, and tools in AWS that unite them.
Service Infrastructure
AWS is a collection of services that is used by customers like you and I. AWS is responsible for the security and reliability of the services that we use, so we do not have to waste time patching, updating, and deploying these services. However, we are still responsible for using the service correctly and ensuring that the software we deploy on those services is secure.
Not every service is available in every region. You can check this list to see what services are available in each region. In addition to availability, some services only span a region or availability zone at a time. For example, the resources for Service A in us-east-1 might not be able to “see” the resources in Service A that are in us-west-2. Some services are “global” services where its resources are usable across all regions. Examples include AWS IAM and AWS Route 53. AWS provides a list of global services in the AWS General Reference. I highly recommend that you review the content of AWS’s whitepaper on fault isolation boundaries to learn more about regional and global services, and the underlying infrastructure that makes services work.
Service API’s
In order to use a service, we must talk to its public HTTPS API. Other public API’s may also be available, but at a minimum an HTTPS API is exposed. Internally in AWS, this public API is often defined with an Interface Description Language called Smithy. This HTTPS API is not necessarily a “RESTful” API, and nor does every HTTPS API use the same data representation. Some services communicate with XML based messages, and others use JSON. This makes communicating with service APIs a mess. However, we should not be attempting to communicate with these APIs directly. Instead, we should utilize the SDK’s that AWS provides.
Every service’s API consists of a set of Actions that users can perform. Most of these Actions are made against a Resource that the Service provides, but some Actions do not need a Resource. The User Guide for each service will list what Resources the Service provides and explain every Action available for that Service.
Every Resource in AWS is identified with an Amazon Resource Number (ARN). This ARN identifier follows a specific format and uniquely identifies every single resource created.
If you want to see all the resources created in your AWS account, you have to use the AWS Resource Explorer. This service will build up an index of resources across all AWS regions that belong to your AWS account.
AWS CLI v2 Usage
The AWS CLI v2 is a tool you can use to quickly manage your AWS resources, and allows for automated/scripted management of resources. Each service has its own set of commands and subcommands in the CLI, and you can get the documentation for each command and subcommand by running: aws command help or aws command subcommand help.
Every option passed to the CLI are given in the --long-form. If you want to pass in the contents of a file as the value for an option, you can use file:path/to/the/file in the CLI to pass it in.
One of the most common actions you will make in the CLI is tagging resources by passing in the --tags option. You can use two formats for passing in the list of tags for a resource: shorthand syntax and JSON syntax.
Shorthand syntax is of the form: --tags Key=color,Value=blue Key=flavor,Value=blueberry.
JSON syntax is of the form: --tags '[{"Key":"Scent","Value":"Vanilla"},{"Key":"Price","Value":"$5.00"}]'
Recommended Reading
This guide only serves to connect ideas already presented in AWS documentation to provide a more complete learning path. After reading this, you should take the time to read these resources as well:
Bookmarks to Keep
Here are some links that I recommend adding to your bookmarks list for quickly looking up AWS information:
- AWS Services Documentation
- AWS CLI v2 Manual
- AWS Regional Service Availability
- AWS Whitepapers
- AWS General Reference