Learning about CI/CD can be a tricky task, especially if you're unfarmiliar with the technologies available, and how to use them. AWS, Amazon's cloud-based services, is one such tool that can help accomplish a lot of your deployment needs. However, it can be a steep learning curve to getting started. Whether it's a front-end application, or an app needing a back-end, AWS can simplify some of the Dev Ops-related tasks for you.
This guide is a first of a series of helpful tips for making your deployments to AWS easier to manage.
In this installment, we'll walk through:
Note: This guide assummes you've already created an account to utilize AWS features.
AWS CLI vs Amplify CLI
First, aws-cli is different from amplify-cli. Where
aws-cli controls credentials for AWS services, the other can also modify access, but mainly controls the deployment similar to git's version control. Because both have some level of access control, which to use and why can be confusing questions.
Access and Logging in via Amplify CLI
The access type of the account (non-SSO or SSO) determines which way you login to perform
amplify-cli commands. Using
amplify configure, you could setup access key id, and secret access key. These credentials would be stored under a profile name (usually
# on macOS and linux $ cat ~/.aws/credentials [default] aws_access_key_id = <a_key_id> aws_secret_access_key = <a_secret>
Then, when performing
amplify pull, it asks for the type of access to use authentication:
AWS profile AWS access keys
Normally, choosing the first option would get you going. Choosing profile wouldn't work in this scenario because it expects those access credentials. Profile here is not the same as the one stored at
~/.aws/credentials. These credentials are bound to an IAM user setup under the account used to access the AWS. (Verify this by going to IAM > Users).
What happens when you need to switch between instances of AWS accounts that contain their own application? Eventually, using access keys becomes a hassle because you'd have to create a new IAM user for each instance, then store multiple profiles in your credentials document with unique profile names to distinguish them. An easier solution would be to use the account level access to AWS as the single access point for these app instances.
Using AWS SSO for Amplify CLI
One solution to this problem is to setup SSO for AWS account(s) then utilize the same login for every app instance that SSO account has access to.
To do this, first follow steps here to configure a named profile to use AWS SSO. Continue onto the section "Using an AWS SSO enabled named profile" to login which should open a browser to finalize authentication via
aws-cli. However, the AWS doc misses a crucial step before you can use the new profile. Notice how that profile was setup for
aws-cli, and not
amplify-cli. The newly created profile lives under aws config:
$ cat ~/.aws/config [profile my-dev-profile] sso_start_url = https://my-sso-portal.awsapps.com/start sso_region = us-east-1 sso_account_id = 123456789011 sso_role_name = readOnly region = us-west-2 output = json
Why is this a problem? Let's try to perform an
amplify pull again. We are asked the same authentication question as before (assuming previous access timed out already). Choosing the first option again gives an error that access key and secret access key are missing.
AWS profile AWS access keys
To connect the new profile, simply intsall aws-sso-util. Once installed, selecting the
AWS profile option will now work for any app.
Some AWS resolutions aren't obvious, and it can be time-consuming finding the right information to help move development along. The tips presented here are subject to change due to amplify's ever-chaning ecosystem, and the many applications that utilize its core features.
The next article will feature how to perform a migration in AWS using Amplify.