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 default
).
# 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.
Conclusion
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.