[Not sure this is the correct forum for this question, but I'll give it a shot.]
I'm looking at duplicating an existing solution built on AWS into an AWS China account. From what I've read in AWS' getting started blog post and AWS China's list of services per region, it seems to me that deploying a solution in Beijing or Ningxia using the AWS services we're used to and dependent on would be feasible. But since you cannot create an AWS China account without having a business license (which seems to be a topic in itself, hmm), it seems impossible to actually try things out to get a feel for if there are any differences. I also cannot seem to find any blog posts with testimonies, experiences from developers or architects who've done this, which is surprising.
Basically I want to understand if taking an existing solution built on AWS and setting it up on Chinese infrastructure is straightforward or if I should expect some differences in how things work etc. I know that AWS does not operate these two regions themselves, but through Chinese partner companies. But I'm not sure if the service capabilities, APIs etc are identical (even including the timing of releases of new versions etc).
The only real limitations I can find on the AWS blog is that the free tier is not available, and that EC2 classic instances is not supported. But let's say I have a solution using very stadnard AWS services like Cloudfront, S3, DynamoDB, Lambda, ECS, Elastic Beanstalk, Cognito, KMS etc. Will it be fairly simple to migrate it to an AWS China account or should I expect a struggle?
Regarding the difference, basically AWS China and AWS Global are two seperate cloud and they are not connected to earch other, thus they will have separate Marketplace,Endpoints and ARNs, different service capablities etc. However those differences are not capatured in such details in official AWS documentation.
For example most security related features, landing zone related feature are not available in AWS China. I have tried to customize some AWS global solutions to China, and met lot of issues and challenges, so plug and play won't work here. The best way is to have some parnters or local presence to overcome those challenges especially the team with similar capabilities.
Related
I’m my scenario wants to separate out the production environment from our development environments.
We'd like to only have our production systems on one AWS account and all other systems and services on another.
I'd like to split/separate for billing purposes. If I do add more monitoring services many charge by the number of running instances. I have considerably more running instances than I need to monitor though so I'd like the separation. This also would make managing permissions in the future a lot easier I believe (e.g. security hub scores wouldn't be affected by LMS instances).
I'd like to split out all public facing assets to a separate AWS account. So RDS, all EC2 instances relating to prod-webserver (instances, target group, AMI, scaling, VPC, etc.), S3 cloudfront.abc.com bucket, jenkins, OpenVPN, all Seoul assets.
Perhaps I could achieve the goal with 'Organizations' or the 'Control Tower' as well. Could anyone please advise what would be best in my scenario? Is there Better alternative for this ?
The fact that you was to split for billing purposes means you should use separate AWS Accounts. While you could split some billing by tags within a single account, it's much easier to use multiple accounts to split the billing.
The typical split is Production / Testing / Development.
You can join the accounts together by using AWS Organizations, which gives some overall security controls.
Separating workloads and environments is considered a best practice in AWS according to the AWS Well-Architected Framework. Nowadays Control Tower (which builds upon AWS Organizations) is the standard for building multi-account setups in AWS.
Regarding multi-account setups I recommend reading the Organizing Your AWS Environment Using Multiple Accounts.
Also have a look at the open-source AWS Quickstart superwerker which sets up a well-architected AWS landing zone using AWS Control Tower, Security Hub, GuardDuty, and more.
AWS provides a lot information about this topic. E.g. a very detailed Whitepaper about Organizing Your AWS Environment in which they say
Using multiple AWS accounts to help isolate and manage your business applications and data can
help you optimize across most of the AWS Well-Architected Framework pillars, including operational
excellence, security, reliability, and cost optimization.
With accounts, you logically separate all resources (unless you allow something else) and therefore ensure independence between e.g. the development environment and the production environment.
You should also take a look at Organizational Units (OUs)
The following benefits of using OUs helped shape the Recommended OUs and accounts and Patterns for organizing your AWS accounts.
Group similar accounts based on function
Apply common policies
Share common resources
Provision and manage common resources
Control Tower is a tool which allows you to manage all your AWS accounts in one place. You can apply policies for every account, OU, or prohibit regions. You can use the Account Factory to create new accounts based on blueprints.
But still you need to collect a lot of knowledge about these tools and best practices because they're just that. Best practices and recommendations you can use to get started and build a good foundation, but they're nothing you can fully rely on because you may have individual factors.
So understanding these factor and consequences is very important.
At home, I use AWS Amplify to host my personal portfolio website since it is so easy and cheap to host.
At work, they have me making other SPAs (in vue.js) and putting the code in private GitHub repos,
but I have to host the websites on EC2 instances and push the code using AWS CodeDeploy/CodePipeline.
Using EC2s to do this is so much more expensive
(Amplify: $12-20/year for domain name, EC2: ~$80-90/year for compute time)
and time consuming.
Is there a reason someone might
not want to use Amplify when building SPAs?
My initial thought is that using CodePipeline might get the user to the
page faster since it's already built and ready to go. Although the site I have in mind is for internal users and
will won't be visited very often, maybe a few times a week. Is that right? Feel free to correct me / my assumptions.
I wasn't able to find much online, but talking to AWS professionals helped me find an answer:
AWS Amplify is a managed service, so you have much less control over the environment/installed packages that might affect your website / you have to deal with other implied disadvantages of managed services
The build time will eventually cost more than it is to run the EC2 if a lot of people visit the site
You don't have the ability to use load balancers to distribute traffic
You may see here https://aws.amazon.com/blogs/aws/host-your-apps-with-aws-amplify-console-from-the-aws-amplify-cli/ that is mentioned about AWS Amplify are able to use the:
Git repo / Codecommit
AWS Cloudfront
AWS S3
With the AWS Amplify also can do continuous deployment similar like AWS Codepipelines
Perhaps that can help you
I'm trying to understand the various steps and requirements I need to go through in order to make our website available from China, both on the regulation side (Great Firewall) but also on the technical side (technical limitations and changes to perform) for https://unly.org/
Right now, it doesn't seem to be allowed: http://www.chinafirewalltest.com/?siteurl=https%3A%2F%2Funly.org%2F
I don't need nor want to own a .ch website, I just want to make my website available for Chinese at https://unly.org/. Also, the website is currently hosted on AWS Lambda (using the Serverless framework), and only deployed in the eu-west-1 region (Ireland) only.
The website doesn't sell anything online: It's an information website, not e-commerce.
I've looked into this issue for a few hours, but I'm a bit lost regarding the exact steps needed to make it happen.
Here are a few questions I haven't found answers for:
Does deploying the lambda to cn-north-1 (China Beijing) is a requirement or can Chinese users access my eu-west-1 lambda if I get an ICP license?
Regardless of the deploying region, I seem to need an ICP License, as the AWS FAQ says at
https://www.amazonaws.cn/en/about-aws/china/faqs/#new%20step:
Q: Do I need to file for ICP Recordal or ICP License if I want to host public content on AWS China (Beijing) Region or AWS China (Ningxia) Region?
Yes. In accordance with Chinese laws and regulations, if you use either AWS China Region to host a website providing non-commercial internet information services, you must undertake filing procedures for a non-commercial website (“ICP Recordal”) through the relevant government authority. If you use either AWS China Region to host a website providing commercial internet information services, you must obtain a value-added telecommunications license for a commercial website (“ICP License”) from the relevant government authority. You may be required to produce your ICP Recordal or ICP License, as applicable, before you host public content using one of the AWS China Regions.
AWS China (Beijing) Region is operated by Sinnet, who is responsible for content hosted in the Beijing Region, while AWS China (Ningxia) Region is operated by NWCD, who is responsible for content hosted in the Ningxia Region. Both Sinnet and NWCD provide support at no additional charge for customers seeking ICP related services, though customers are responsible for any fees imposed by the applicable government authorities. To learn more about the filing procedures, please visit Sinnet at http://www.sinnet.com.cn/service.aspx?PartNodeId=35 and NWCD at http://nwcdcloud.cn/ICP.aspx.
As for actually getting the license, it's a bit out of topic here, but I couldn't understand the first provider workflow:
http://www.sinnet.com.cn/en/ website is a mix of english and chinese and I got lost in translation (even when using their english website version)
http://nwcdcloud.cn/ContactUs.aspx seems to require to send an email to support#amazonaws.com.cn, no idea what happens next
Anyway, the process seems to take around 4-6 weeks. So, it likely takes even more time than that.
Regarding the technical details now, it seems like the China region (cn-north-1 Beijing and cn-northwest-1 Ningxia) behave in a very particular way on AWS Lambda.
They only support REGIONAL endpoints
They do not support native Serverless environment variables
See
https://github.com/serverless/serverless/pull/4665#issuecomment-365843810
Lambda - EnvironmentVariablesFeature is not supported in cn-north-1 region
Also, there are technical impacts on the website itself:
Google services are banned, or limited (Google Analytics (limited), Google Tag Manager, Google Fonts (banned)) and must be changed, converted to owned CDN, etc.
And I've probably missed other technical limitations, since that's just those I learned about within 2h of digging around.
Are there other steps I overlooked? (regulation or technical)
Do you have any advices or feedback about how to make a website hosted on AWS Lambda available in China?
Since your question contains several different aspects, I'll split my answer into two parts:
Make your website available from China
From my experience, it doesn't matter whether you're using a .com or .cn domain. You could use a .cn domain to host a Chinese version of your website, of course. But I don't think it would help with any of the problems you describe
For a "standard", international website hosted outside China, it depends on the GFW whether it's accessible from inside China or not. In your case, it seems to be blocked
Google services are banned indeed. There's nothing you can do about it
In order to officially register your website (to get it "unblocked"), you do need an ICP license as you've already found out. A good overview about the registration workflow is given by Alibaba Cloud
I've never went through the complete exercise, but I doubt it's possible without some help from somebody speaking Chinese
AWS Lambda
The setup you describe - deploying lambda functions to two different regions, one being somehow non "standard" (the Chinese one) - might create problems on the techical side as well. I'd suggest starting with a simple (one region) setup first until you get the ICP problem fixed, maybe using some China-aware CDN provider. Or you try with a "standard" AWS region closer to China; for this case, some people recommend the Singapore region.
I would like to develop a web application for AWS practice labs where I can create
users and allow them to practice their AWS knowledge with live labs just like https://qwiklabs.com/
In this application, according to labs I need to provision AWS resources automatically as per the lab requirements and allow the user to complete the lab
with limited access.
So, Please share your suggestion, how can I do this whole setup with my AWS account.
Thanks in advance.
I took a look at how QwikLabs provided their service early on when they first started offering services. Back then their IAM policies were not well written and I could see the resources that they were provisioning. I studied many of their CloudFormation templates. This is not true today as they have tightened everything very well.
1) They developed their own management system for managing users, payments, account access, etc.
2) They use CloudFormation with very tight IAM permissions to create the labs that you access. Via IAM policies they control what you can do and access. They also time you out and drop everything after a period of time. This is one of the better/best executions of CloudFormation that I have experienced.
Their setup is actually very well thought-out and executed.
I'm a noobie to CloudFormation. But reading the documentation for CloudFormation, Amazon seems to think it is the method we should use to consistently, repeatedly deploy a given topology of AWS service instances. However AWS has been around for over a decade, and the AWS push for CF seems to be only within the last 5 years.
I stumbled across a great post, AWS OpsWorks vs AWS Beanstalk vs AWS CloudFormation?, which explores the strengths of different AWS deployment offerings. And given the needs of my organization for flexible and repeatable IaaS/PaaS deployments, CF seems to fit the bill.
What I want to know is: How prevalent is the use of CF, vs other "template" deployment technologies? What is YOUR team using for deploying repeated configurations of AWS services?
How usable/learnable is it? If I adopt CF, how likely is it that existing developers on AWS will already be familiar with it, and be able to use it straight off the bat? CF seems to support many or most AWS services already, but are people actually using it to repeatedly stamp out identically-configured topologies of services?
Or do most teams favor a simpler, less endlessly-configurable option? And if so, why?
What pitfalls do I need to watch out for when using CloudFormation Templates? What doesn't CF handle, which it really should?
I'll try to answer most of your questions based on my personal experience:
What I want to know is: How prevalent is the use of CF, vs other "template" deployment technologies?
I can't assert to specific usage distribution, but I know people who use Terraform. Although Terraform supports CF, my team decided not to use it simply because CF already satisfies our needs.
What is YOUR team using for deploying repeated configurations of AWS
services?
My team uses CloudFormation (without Terraform) to deploy our whole infrastructure to AWS
How usable/learnable is it?
Pretty easy. Start with a small template (ideally YAML), then build up from there. The aws cloudformation deploy will speed up your feedback loop.
If I adopt CF, how likely is it that existing developers on AWS will already be familiar with it, and be able to use it straight off the bat?
I think developers who are familiar to AWS can easily pick up CF. If you can find your way around AWS documentation, CF is just another service to learn. I can't assert to the likeliness that existing AWS devs are familiar with CF.
CF seems to support many or most AWS services already, but are people actually using it to repeatedly stamp out identically-configured topologies of services?
My team uses it to provision testing and production environments that have the same topology. Some parts of our infrastructure is duplicated for redundancy using shared CF templates.
What pitfalls do I need to watch out for when using CloudFormation Templates?
You have to watch out for some CF limits, namely the template body's maximum size, which is capped at 46KB. We have hit this limit a few times, especially when provisioning EC2 instances with larger user data scripts. That being said, you should not hit that limit early on, and there are many workarounds
What doesn't CF handle, which it really should?
From the top of my head: Elastic Transcoder, EC2 AMIs, API Gateway VPC Links. My team has circumvented these limitations using Lambda-backed custom resources, which allow you to extend CF to your needs.
Overall, my team is very satisfied with CloudFormation. It definitely helps us maintain our AWS accounts in order.
Hope this helps!